Single logout functionality for a multi-tenant identity and data security management cloud service

ABSTRACT

A cloud-based identity and access management system that implements single sign-on (“SSO”) receives a first request for an identity management service configured to allow for accessing applications. Embodiments send the first request to a first microservice, where the first microservice performs the identity management service by generating a token. The first microservice generates the token at least in part by sending a second request to a SSO. The SSO microservice implements an SSO and generates a cookie that includes a global state and is used for communicating with different microservices. Embodiments receive a single log-out (SLO) of the SSO and use the cookie to iteratively log-out of the applications, where, after each log-out of an application of a first protocol, a redirect is performed to the SSO microservice to trigger log-out of applications of a different protocol.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority of U.S. Provisional Patent ApplicationSer. No. 62/394,345, filed on Sep. 14, 2016, the disclosure of which ishereby incorporated by reference.

FIELD

One embodiment is directed generally to identity management, and inparticular, to identity management in a cloud system.

BACKGROUND INFORMATION

Generally, the use of cloud-based applications (e.g., enterprise publiccloud applications, third-party cloud applications, etc.) is soaring,with access coming from a variety of devices (e.g., desktop and mobiledevices) and a variety of users (e.g., employees, partners, customers,etc.). The abundant diversity and accessibility of cloud-basedapplications has led identity management and access security to become acentral concern. Typical security concerns in a cloud environment areunauthorized access, account hijacking, malicious insiders, etc.Accordingly, there is a need for secure access to cloud-basedapplications, or applications located anywhere, regardless of from whatdevice type or by what user type the applications are accessed.

SUMMARY

One embodiment is a cloud-based identity and access management systemthat implements single sign-on (“SSO”). Embodiments receive a firstrequest for an identity management service configured to allow foraccessing applications. Embodiments send the first request to a firstmicroservice, where the first microservice performs the identitymanagement service by generating a token. The first microservicegenerates the token at least in part by sending a second request to aSSO microservice, where the SSO microservice is configured to provideSSO functionality across different microservices that are based ondifferent protocols. The SSO microservice implements an SSO andgenerates a cookie that includes a global state and is used forcommunicating with different microservices. Embodiments receive a singlelog-out (SLO) of the SSO and use the cookie to iteratively log-out ofthe applications, where, after each log-out of an application of a firstprotocol, a redirect is performed to the SSO microservice to triggerlog-out of applications of a different protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-5 are block diagrams of example embodiments that providecloud-based identity management.

FIG. 6 is a block diagram providing a system view of an embodiment.

FIG. 6A is a block diagram providing a functional view of an embodiment.

FIG. 7 is a block diagram of an embodiment that implements Cloud Gate.

FIG. 7A is a block diagram illustrating host identifier functionality inan embodiment that implements Cloud Gate.

FIG. 8 illustrates an example system that implements multiple tenanciesin one embodiment.

FIG. 9 is a block diagram of a network view of an embodiment.

FIG. 10 is a block diagram of a system architecture view of singlesign-on (“SSO”) functionality in one embodiment.

FIG. 10A illustrates an example block diagram of SSO runtime in oneembodiment.

FIG. 10B illustrates an example state and flow diagram of SSOfunctionality in one embodiment.

FIG. 11 is a message sequence flow of SSO functionality in oneembodiment.

FIG. 12 illustrates an example of a distributed data grid in oneembodiment.

FIG. 13 is a flow diagram of identity and access managementfunctionality in accordance with an embodiment.

FIG. 14 is a logout flow illustrating various functionality ofcomponents and cookie propagation functionality in accordance with oneembodiment.

DETAILED DESCRIPTION

Embodiments provide single sign-on (“SSO”) functionality in an IdentityCloud Service (“IDCS”) that provides a multi-tenant, cloud-scale,identity and access management (“IAM”) platform. In one embodiment, theSSO functionality is implemented by providing a global session and thengenerating protocol-specific tokens based on the global session.Embodiments further provide single logout (“SLO”) functionality by usinga cookie to iteratively log out of multiple applications and using aredirect so secure information is not stored on the cookie.

Embodiments provide an identity cloud service that implements amicroservices based architecture and provides multi-tenant identity anddata security management and secure access to cloud-based applications.Embodiments support secure access for hybrid cloud deployments (i.e.,cloud deployments which include a combination of a public cloud and aprivate cloud). Embodiments protect applications and data both in thecloud and on-premise. Embodiments support multi-channel access via web,mobile, and application programming interfaces (“APIs”). Embodimentsmanage access for different users, such as customers, partners, andemployees. Embodiments manage, control, and audit access across thecloud as well as on-premise. Embodiments integrate with new and existingapplications and identities. Embodiments are horizontally scalable.

One embodiment is a system that implements a number of microservices ina stateless middle tier environment to provide cloud-based multi-tenantidentity and access management services. In one embodiment, eachrequested identity management service is broken into real-time andnear-real-time tasks. The real-time tasks are handled by a microservicein the middle tier, while the near-real-time tasks are offloaded to amessage queue. Embodiments implement access tokens that are consumed bya routing tier and a middle tier to enforce a security model foraccessing the microservices. Accordingly, embodiments provide acloud-scale IAM platform based on a multi-tenant, microservicesarchitecture.

One embodiment provides an identity cloud service that enablesorganizations to rapidly develop fast, reliable, and secure services fortheir new business initiatives. In one embodiment, the identity cloudservice provides a number of core services, each of which solving aunique challenge faced by many enterprises. In one embodiment, theidentity cloud service supports administrators in, for example, initialon-boarding/importing of users, importing groups with user members,creating/updating/disabling/enabling/deleting users,assigning/un-assigning users into/from groups,creating/updating/deleting groups, resetting passwords, managingpolicies, sending activation, etc. The identity cloud service alsosupports end users in, for example, modifying profiles, settingprimary/recovery emails, verifying emails, unlocking their accounts,changing passwords, recovering passwords in case of forgotten password,etc.

Unified Security of Access

One embodiment protects applications and data in a cloud environment aswell as in an on-premise environment. The embodiment secures access toany application from any device by anyone. The embodiment providesprotection across both environments since inconsistencies in securitybetween the two environments may result in higher risks. For example,such inconsistencies may cause a sales person to continue having accessto their Customer Relationship Management (“CRM”) account even afterthey have defected to the competition. Accordingly, embodiments extendthe security controls provisioned in the on-premise environment into thecloud environment. For example, if a person leaves a company,embodiments ensure that their accounts are disabled both on-premise andin the cloud.

Generally, users may access applications and/or data through manydifferent channels such as web browsers, desktops, mobile phones,tablets, smart watches, other wearables, etc. Accordingly, oneembodiment provides secured access across all these channels. Forexample, a user may use their mobile phone to complete a transactionthey started on their desktop.

One embodiment further manages access for various users such ascustomers, partners, employees, etc. Generally, applications and/or datamay be accessed not just by employees but by customers or third parties.Although many known systems take security measures when onboardingemployees, they generally do not take the same level of securitymeasures when giving access to customers, third parties, partners, etc.,resulting in the possibility of security breaches by parties that arenot properly managed. However, embodiments ensure that sufficientsecurity measures are provided for access of each type of user and notjust employees.

Identity Cloud Service

Embodiments provide an IDCS that is a multi-tenant, cloud-scale, IAMplatform. IDCS provides authentication, authorization, auditing, andfederation. IDCS manages access to custom applications and servicesrunning on the public cloud, and on-premise systems. In an alternativeor additional embodiment, IDCS may also manage access to public cloudservices. For example, IDCS can be used to provide SSO functionalityacross such variety of services/applications/systems.

Embodiments are based on a multi-tenant, microservices architecture fordesigning, building, and delivering cloud-scale software services.Multi-tenancy refers to having one physical implementation of a servicesecurely supporting multiple customers buying that service. A service isa software functionality or a set of software functionalities (such asthe retrieval of specified information or the execution of a set ofoperations) that can be reused by different clients for differentpurposes, together with the policies that control its usage (e.g., basedon the identity of the client requesting the service). In oneembodiment, a service is a mechanism to enable access to one or morecapabilities, where the access is provided using a prescribed interfaceand is exercised consistent with constraints and policies as specifiedby the service description.

In one embodiment, a microservice is an independently deployableservice. In one embodiment, the term microservice contemplates asoftware architecture design pattern in which complex applications arecomposed of small, independent processes communicating with each otherusing language-agnostic APIs. In one embodiment, microservices aresmall, highly decoupled services and each may focus on doing a smalltask. In one embodiment, the microservice architectural style is anapproach to developing a single application as a suite of smallservices, each running in its own process and communicating withlightweight mechanisms (e.g., an Hypertext Transfer Protocol (“HTTP”)resource API). In one embodiment, microservices are easier to replacerelative to a monolithic service that performs all or many of the samefunctions. Moreover, each of the microservices may be updated withoutadversely affecting the other microservices. In contrast, updates to oneportion of a monolithic service may undesirably or unintentionallynegatively affect the other portions of the monolithic service. In oneembodiment, microservices may be beneficially organized around theircapabilities. In one embodiment, the startup time for each of acollection of microservices is much less than the startup time for asingle application that collectively performs all the services of thosemicroservices. In some embodiments, the startup time for each of suchmicroservices is about one second or less, while the startup time ofsuch single application may be about a minute, several minutes, orlonger.

In one embodiment, microservices architecture refers to a specialization(i.e., separation of tasks within a system) and implementation approachfor service oriented architectures (“SOAs”) to build flexible,independently deployable software systems. Services in a microservicesarchitecture are processes that communicate with each other over anetwork in order to fulfill a goal. In one embodiment, these servicesuse technology-agnostic protocols. In one embodiment, the services havea small granularity and use lightweight protocols. In one embodiment,the services are independently deployable. By distributingfunctionalities of a system into different small services, the cohesionof the system is enhanced and the coupling of the system is decreased.This makes it easier to change the system and add functions andqualities to the system at any time. It also allows the architecture ofan individual service to emerge through continuous refactoring, andhence reduces the need for a big up-front design and allows forreleasing software early and continuously.

In one embodiment, in the microservices architecture, an application isdeveloped as a collection of services, and each service runs arespective process and uses a lightweight protocol to communicate (e.g.,a unique API for each microservice). In the microservices architecture,decomposition of a software into individual services/capabilities can beperformed at different levels of granularity depending on the service tobe provided. A service is a runtime component/process. Each microserviceis a self-contained module that can talk to other modules/microservices.Each microservice has an unnamed universal port that can be contacted byothers. In one embodiment, the unnamed universal port of a microserviceis a standard communication channel that the microservice exposes byconvention (e.g., as a conventional Hypertext Transfer Protocol (“HTTP”)port) and that allows any other module/microservice within the sameservice to talk to it. A microservice or any other self-containedfunctional module can be generically referred to as a “service”.

Embodiments provide multi-tenant identity management services.Embodiments are based on open standards to ensure ease of integrationwith various applications, delivering IAM capabilities throughstandards-based services.

Embodiments manage the lifecycle of user identities which entails thedetermination and enforcement of what an identity can access, who can begiven such access, who can manage such access, etc. Embodiments run theidentity management workload in the cloud and support securityfunctionality for applications that are not necessarily in the cloud.The identity management services provided by the embodiments may bepurchased from the cloud. For example, an enterprise may purchase suchservices from the cloud to manage their employees' access to theirapplications.

Embodiments provide system security, massive scalability, end userusability, and application interoperability. Embodiments address thegrowth of the cloud and the use of identity services by customers. Themicroservices based foundation addresses horizontal scalabilityrequirements, while careful orchestration of the services addresses thefunctional requirements. Achieving both goals requires decomposition(wherever possible) of the business logic to achieve statelessness witheventual consistency, while much of the operational logic not subject toreal-time processing is shifted to near-real-time by offloading to ahighly scalable asynchronous event management system with guaranteeddelivery and processing. Embodiments are fully multi-tenant from the webtier to the data tier in order to realize cost efficiencies and ease ofsystem administration.

Embodiments are based on industry standards (e.g., OpenID Connect,OAuth2, Security Assertion Markup Language 2 (“SAML2”), System forCross-domain Identity Management (“SCIM”), Representational StateTransfer (“REST”), etc.) for ease of integration with variousapplications. One embodiment provides a cloud-scale API platform andimplements horizontally scalable microservices for elastic scalability.The embodiment leverages cloud principles and provides a multi-tenantarchitecture with per-tenant data separation. The embodiment furtherprovides per-tenant customization via tenant self-service. Theembodiment is available via APIs for on-demand integration with otheridentity services, and provides continuous feature release.

One embodiment provides interoperability and leverages investments inidentity management (“IDM”) functionality in the cloud and on-premise.The embodiment provides automated identity synchronization fromon-premise Lightweight Directory Access Protocol (“LDAP”) data to clouddata and vice versa. The embodiment provides a SCIM identity bus betweenthe cloud and the enterprise, and allows for different options forhybrid cloud deployments (e.g., identity federation and/orsynchronization, SSO agents, user provisioning connectors, etc.).

Accordingly, one embodiment is a system that implements a number ofmicroservices in a stateless middle tier to provide cloud-basedmulti-tenant identity and access management services. In one embodiment,each requested identity management service is broken into real-time andnear-real-time tasks. The real-time tasks are handled by a microservicein the middle tier, while the near-real-time tasks are offloaded to amessage queue. Embodiments implement tokens that are consumed by arouting tier to enforce a security model for accessing themicroservices. Accordingly, embodiments provide a cloud-scale IAMplatform based on a multi-tenant, microservices architecture.

Generally, known systems provide siloed access to applications providedby different environments, e.g., enterprise cloud applications, partnercloud applications, third-party cloud applications, and customerapplications. Such siloed access may require multiple passwords,different password policies, different account provisioning andde-provisioning schemes, disparate audit, etc. However, one embodimentimplements IDCS to provide unified IAM functionality over suchapplications. FIG. 1 is a block diagram 100 of an example embodimentwith IDCS 118, providing a unified identity platform 126 for onboardingusers and applications. The embodiment provides seamless user experienceacross various applications such as enterprise cloud applications 102,partner cloud applications 104, third-party cloud applications 110, andcustomer applications 112. Applications 102, 104, 110, 112 may beaccessed through different channels, for example, by a mobile phone user108 via a mobile phone 106, by a desktop computer user 116 via a browser114, etc. A web browser (commonly referred to as a browser) is asoftware application for retrieving, presenting, and traversinginformation resources on the World Wide Web. Examples of web browsersare Mozilla Firefox®, Google Chrome®, Microsoft Internet Explorer®, andApple Safari®.

IDCS 118 provides a unified view 124 of a user's applications, a unifiedsecure credential across devices and applications (via identity platform126), and a unified way of administration (via an admin console 122).IDCS services may be obtained by calling IDCS APIs 142. Such servicesmay include, for example, login/SSO services 128 (e.g., OpenID Connect),federation services 130 (e.g., SAML), token services 132 (e.g., OAuth),directory services 134 (e.g., SCIM), provisioning services 136 (e.g.,SCIM or Any Transport over Multiprotocol (“AToM”)), event services 138(e.g., REST), and role-based access control (“RBAC”) services 140 (e.g.,SCIM). IDCS 118 may further provide reports and dashboards 120 relatedto the offered services.

Integration Tools

Generally, it is common for large corporations to have an IAM system inplace to secure access to their on-premise applications. Businesspractices are usually matured and standardized around an in-house IAMsystem such as “Oracle IAM Suite” from Oracle Corp. Even small to mediumorganizations usually have their business processes designed aroundmanaging user access through a simple directory solution such asMicrosoft Active Directory (“AD”). To enable on-premise integration,embodiments provide tools that allow customers to integrate theirapplications with IDCS.

FIG. 2 is a block diagram 200 of an example embodiment with IDCS 202 ina cloud environment 208, providing integration with an AD 204 that ison-premise 206. The embodiment provides seamless user experience acrossall applications including on-premise and third-party applications, forexample, on-premise applications 218 and various applications/servicesin cloud 208 such as cloud services 210, cloud applications 212, partnerapplications 214, and customer applications 216. Cloud applications 212may include, for example, Human Capital Management (“HCM”), CRM, talentacquisition (e.g., Oracle Taleo cloud service from Oracle Corp.),Configure Price and Quote (“CPQ”), etc. Cloud services 210 may include,for example, Platform as a Service (“PaaS”), Java, database, businessintelligence (“BI”), documents, etc.

Applications 210, 212, 214, 216, 218, may be accessed through differentchannels, for example, by a mobile phone user 220 via a mobile phone222, by a desktop computer user 224 via a browser 226, etc. Theembodiment provides automated identity synchronization from on-premiseAD data to cloud data via a SCIM identity bus 234 between cloud 208 andthe enterprise 206. The embodiment further provides a SAML bus 228 forfederating authentication from cloud 208 to on-premise AD 204 (e.g.,using passwords 232).

Generally, an identity bus is a service bus for identity relatedservices. A service bus provides a platform for communicating messagesfrom one system to another system. It is a controlled mechanism forexchanging information between trusted systems, for example, in aservice oriented architecture (“SOA”). An identity bus is a logical busbuilt according to standard HTTP based mechanisms such as web service,web server proxies, etc. The communication in an identity bus may beperformed according to a respective protocol (e.g., SCIM, SAML, OpenIDConnect, etc.). For example, a SAML bus is an HTTP based connectionbetween two systems for communicating messages for SAML services.Similarly, a SCIM bus is used to communicate SCIM messages according tothe SCIM protocol.

The embodiment of FIG. 2 implements an identity (“ID”) bridge 230 thatis a small binary (e.g., 1 MB in size) that can be downloaded andinstalled on-premise 206 alongside a customer's AD 204. ID Bridge 230listens to users and groups (e.g., groups of users) from theorganizational units (“OUs”) chosen by the customer and synchronizesthose users to cloud 208. In one embodiment, users' passwords 232 arenot synchronized to cloud 208. Customers can manage application accessfor users by mapping IDCS users' groups to cloud applications managed inIDCS 208. Whenever the users' group membership is changed on-premise206, their corresponding cloud application access changes automatically.

For example, an employee moving from engineering to sales can get nearinstantaneous access to the sales cloud and lose access to the developercloud. When this change is reflected in on-premise AD 204, cloudapplication access change is accomplished in near-real-time. Similarly,access to cloud applications managed in IDCS 208 is revoked for usersleaving the company. For full automation, customers may set up SSObetween on-premise AD 204 and IDCS 208 through, e.g., AD federationservice (“AD/FS”, or some other mechanism that implements SAMLfederation) so that end users can get access to cloud applications 210,212, 214, 216, and on-premise applications 218 with a single corporatepassword 332.

FIG. 3 is a block diagram 300 of an example embodiment that includes thesame components 202, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224,226, 228, 234 as in FIG. 2. However, in the embodiment of FIG. 3, IDCS202 provides integration with an on-premise IDM 304 such as Oracle IDM.Oracle IDM 304 is a software suite from Oracle Corp. for providing IAMfunctionality. The embodiment provides seamless user experience acrossall applications including on-premise and third-party applications. Theembodiment provisions user identities from on-premise IDM 304 to IDCS208 via SCIM identity bus 234 between cloud 202 and enterprise 206. Theembodiment further provides SAML bus 228 (or an OpenID Connect bus) forfederating authentication from cloud 208 to on-premise 206.

In the embodiment of FIG. 3, an Oracle Identity Manager (“OIM”)Connector 302 from Oracle Corp., and an Oracle Access Manager (“OAM”)federation module 306 from Oracle Corp., are implemented as extensionmodules of Oracle IDM 304. A connector is a module that has physicalawareness about how to talk to a system. OIM is an applicationconfigured to manage user identities (e.g., manage user accounts indifferent systems based on what a user should and should not have accessto). OAM is a security application that provides access managementfunctionality such as web SSO; identity context, authentication andauthorization; policy administration; testing; logging; auditing; etc.OAM has built-in support for SAML. If a user has an account in IDCS 202,OIM connector 302 and OAM federation 306 can be used with Oracle IDM 304to create/delete that account and manage access from that account.

FIG. 4 is a block diagram 400 of an example embodiment that includes thesame components 202, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224,226, 234 as in FIGS. 2 and 3. However, in the embodiment of FIG. 4, IDCS202 provides functionality to extend cloud identities to on-premiseapplications 218. The embodiment provides seamless view of the identityacross all applications including on-premise and third-partyapplications. In the embodiment of FIG. 4, SCIM identity bus 234 is usedto synchronize data in IDCS 202 with on-premise LDAP data called “CloudCache” 402. Cloud Cache 402 is disclosed in more detail below.

Generally, an application that is configured to communicate based onLDAP needs an LDAP connection. An LDAP connection may not be establishedby such application through a URL (unlike, e.g., “www.google.com” thatmakes a connection to Google) since the LDAP needs to be on a localnetwork. In the embodiment of FIG. 4, an LDAP-based application 218makes a connection to Cloud Cache 402, and Cloud Cache 402 establishes aconnection to IDCS 202 and then pulls data from IDCS 202 as it is beingrequested. The communication between IDCS 202 and Cloud Cache 402 may beimplemented according to the SCIM protocol. For example, Cloud Cache 402may use SCIM bus 234 to send a SCIM request to IDCS 202 and receivecorresponding data in return.

Generally, fully implementing an application includes building aconsumer portal, running marketing campaigns on the external userpopulation, supporting web and mobile channels, and dealing with userauthentication, sessions, user profiles, user groups, application roles,password policies, self-service/registration, social integration,identity federation, etc. Generally, application developers are notidentity/security experts. Therefore, on-demand identity managementservices are desired.

FIG. 5 is a block diagram 500 of an example embodiment that includes thesame components 202, 220, 222, 224, 226, 234, 402, as in FIGS. 2-4.However, in the embodiment of FIG. 5, IDCS 202 provides secure identitymanagement on demand. The embodiment provides on demand integration withidentity services of IDCS 202 (e.g., based on standards such as OpenIDConnect, OAuth2, SAML2, or SCIM). Applications 505 (which may beon-premise, in a public cloud, or in a private cloud) may call identityservice APIs 504 in IDCS 202. The services provided by IDCS 202 mayinclude, for example, self-service registration 506, password management508, user profile management 510, user authentication 512, tokenmanagement 514, social integration 516, etc.

In this embodiment, SCIM identity bus 234 is used to synchronize data inIDCS 202 with data in on-premise LDAP Cloud Cache 402. Further, a “CloudGate” 502 running on a web server/proxy (e.g., NGINX, Apache, etc.) maybe used by applications 505 to obtain user web SSO and REST API securityfrom IDCS 202. Cloud Gate 502 is a component that secures access tomulti-tenant IDCS microservices by ensuring that client applicationsprovide valid access tokens, and/or users successfully authenticate inorder to establish SSO sessions. Cloud Gate 502 is further disclosedbelow. Cloud Gate 502 (enforcement point similar to webgate/webagent)enables applications running behind supported web servers to participatein SSO.

One embodiment provides SSO and cloud SSO functionality. A general pointof entry for both on-premise IAM and IDCS in many organizations is SSO.Cloud SSO enables users to access multiple cloud resources with a singleuser sign-in. Often, organizations will want to federate theiron-premise identities. Accordingly, embodiments utilize open standardsto allow for integration with existing SSO to preserve and extendinvestment (e.g., until a complete, eventual transition to an identitycloud service approach is made).

One embodiment may provide the following functionalities:

-   -   maintain an identity store to track user accounts, ownership,        access, and permissions that have been authorized,    -   integrate with workflow to facilitate various approvals (e.g.,        management, IT, human resources, legal, and compliance) needed        for applications access,    -   provision SaaS user accounts for selective devices (e.g., mobile        and personal computer (“PC”)) with access to user portal        containing many private and public cloud resources, and    -   facilitate periodic management attestation review for compliance        with regulations and current job responsibilities.

In addition to these functions, embodiments may further provide:

-   -   cloud account provisioning to manage account life cycle in cloud        applications,    -   more robust multifactor authentication (“MFA”) integration,    -   extensive mobile security capabilities, and    -   dynamic authentication options.

One embodiment provides adaptive authentication and MFA. Generally,passwords and challenge questions have been seen as inadequate andsusceptible to common attacks such as phishing. Most business entitiestoday are looking at some form of MFA to reduce risk. To be successfullydeployed, however, solutions need to be easily provisioned, maintained,and understood by the end user, as end users usually resist anythingthat interferes with their digital experience. Companies are looking forways to securely incorporate bring your own device (“BYOD”), socialidentities, remote users, customers, and contractors, while making MFAan almost transparent component of a seamless user access experience.Within an MFA deployment, industry standards such as OAuth and OpenIDConnect are essential to ensure integration of existing multifactorsolutions and the incorporation of newer, adaptive authenticationtechnology. Accordingly, embodiments define dynamic (or adaptive)authentication as the evaluation of available information (i.e., IPaddress, location, time of day, and biometrics) to prove an identityafter a user session has been initiated. With the appropriate standards(e.g., open authentication (“OATH”) and fast identity online (“FIDO”))integration and extensible identity management framework, embodimentsprovide MFA solutions that can be adopted, upgraded, and integratedeasily within an IT organization as part of an end-to-end secure IAMdeployment. When considering MFA and adaptive policies, organizationsmust implement consistent policies across on-premise and cloudresources, which in a hybrid IDCS and on-premise IAM environmentrequires integration between systems.

One embodiment provides user provisioning and certification. Generally,the fundamental function of an IAM solution is to enable and support theentire user provisioning life cycle. This includes providing users withthe application access appropriate for their identity and role withinthe organization, certifying that they have the correct ongoing accesspermissions (e.g., as their role or the tasks or applications usedwithin their role change over time), and promptly de-provisioning themas their departure from the organization may require. This is importantnot only for meeting various compliance requirements but also becauseinappropriate insider access is a major source of security breaches andattacks. An automated user provisioning capability within an identitycloud solution can be important not only in its own right but also aspart of a hybrid IAM solution whereby IDCS provisioning may providegreater flexibility than an on-premise solution for transitions as acompany downsizes, upsizes, merges, or looks to integrate existingsystems with IaaS/PaaS/SaaS environments. An IDCS approach can save timeand effort in one-off upgrades and ensure appropriate integration amongnecessary departments, divisions, and systems. The need to scale thistechnology often sneaks up on corporations, and the ability to deliver ascalable IDCS capability immediately across the enterprise can providebenefits in flexibility, cost, and control.

Generally, an employee is granted additional privileges (i.e.,“privilege creep”) over the years as her/his job changes. Companies thatare lightly regulated generally lack an “attestation” process thatrequires managers to regularly audit their employees' privileges (e.g.,access to networks, servers, applications, and data) to halt or slow theprivilege creep that results in over-privileged accounts. Accordingly,one embodiment may provide a regularly conducted (at least once a year)attestation process. Further, with mergers and acquisitions, the needfor these tools and services increases exponentially as users are onSaaS systems, on-premise, span different departments, and/or are beingde-provisioned or re-allocated. The move to cloud can further confusethis situation, and things can quickly escalate beyond existing, oftenmanually managed, certification methods. Accordingly, one embodimentautomates these functions and applies sophisticated analytics to userprofiles, access history, provisioning/de-provisioning, and fine-grainedentitlements.

One embodiment provides identity analytics. Generally, the ability tointegrate identity analytics with the IAM engine for comprehensivecertification and attestation can be critical to securing anorganization's risk profile. Properly deployed identity analytics candemand total internal policy enforcement. Identity analytics thatprovide a unified single management view across cloud and on-premise aremuch needed in a proactive governance, risk, and compliance (“GRC”)enterprise environment, and can aid in providing a closed-loop processfor reducing risk and meeting compliance regulations. Accordingly, oneembodiment provides identity analytics that are easily customizable bythe client to accommodate specific industry demands and governmentregulations for reports and analysis required by managers, executives,and auditors.

One embodiment provides self-service and access request functionality toimprove the experience and efficiency of the end user and to reducecosts from help desk calls. Generally, while a number of companiesdeploy on-premise self-service access request for their employees, manyhave not extended these systems adequately outside the formal corporatewalls. Beyond employee use, a positive digital customer experienceincreases business credibility and ultimately contributes to revenueincrease, and companies not only save on customer help desk calls andcosts but also improve customer satisfaction. Accordingly, oneembodiment provides an identity cloud service environment that is basedon open standards and seamlessly integrates with existing access controlsoftware and MFA mechanisms when necessary. The SaaS delivery modelsaves time and effort formerly devoted to systems upgrades andmaintenance, freeing professional IT staff to focus on more corebusiness applications.

One embodiment provides privileged account management (“PAM”).Generally, every organization, whether using SaaS, PaaS, IaaS, oron-premise applications, is vulnerable to unauthorized privilegedaccount abuse by insiders with super-user access credentials such assystem administrators, executives, HR officers, contractors, systemsintegrators, etc. Moreover, outside threats typically first breach alow-level user account to eventually reach and exploit privileged useraccess controls within the enterprise system. Accordingly, oneembodiment provides PAM to prevent such unauthorized insider accountuse. The main component of a PAM solution is a password vault which maybe delivered in various ways, e.g., as software to be installed on anenterprise server, as a virtual appliance also on an enterprise server,as a packaged hardware/software appliance, or as part of a cloudservice. PAM functionality is similar to a physical safe used to storepasswords kept in an envelope and changed periodically, with a manifestfor signing them in and out. One embodiment allows for a passwordcheckout as well as setting time limits, forcing periodic changes,automatically tracking checkout, and reporting on all activities. Oneembodiment provides a way to connect directly through to a requestedresource without the user ever knowing the password. This capabilityalso paves the way for session management and additional functionality.

Generally, most cloud services utilize APIs and administrativeinterfaces, which provide opportunities for infiltrators to circumventsecurity. Accordingly, one embodiment accounts for these holes in PAMpractices as the move to the cloud presents new challenges for PAM. Manysmall to medium sized businesses now administer their own SaaS systems(e.g., Office 365), while larger companies increasingly have individualbusiness units spinning up their own SaaS and IaaS services. Thesecustomers find themselves with PAM capabilities within the identitycloud service solutions or from their IaaS/PaaS provider but with littleexperience in handling this responsibility. Moreover, in some cases,many different geographically dispersed business units are trying tosegregate administrative responsibilities for the same SaaSapplications. Accordingly, one embodiment allows customers in thesesituations to link existing PAM into the overall identity framework ofthe identity cloud service and move toward greater security andcompliance with the assurance of scaling to cloud load requirements asbusiness needs dictate.

API Platform

Embodiments provide an API platform that exposes a collection ofcapabilities as services. The APIs are aggregated into microservices andeach microservice exposes one or more of the APIs. That is, eachmicroservice may expose different types of APIs. In one embodiment, eachmicroservice communicates only through its APIs. In one embodiment, eachAPI may be a microservice. In one embodiment, multiple APIs areaggregated into a service based on a target capability to be provided bythat service (e.g., OAuth, SAML, Admin, etc.). As a result, similar APIsare not exposed as separate runtime processes. The APIs are what is madeavailable to a service consumer to use the services provided by IDCS.

Generally, in the web environment of IDCS, a URL includes three parts: ahost, a microservice, and a resource (e.g., host/microservice/resource).In one embodiment, the microservice is characterized by having aspecific URL prefix, e.g., “host/oauth/v1” where the actual microserviceis “oauth/v1”, and under “oauth/v1” there are multiple APIs, e.g., anAPI to request tokens: “host/oauth/v1/token”, an API to authenticate auser: “host/oauth/v1/authorize”, etc. That is, the URL implements amicroservice, and the resource portion of the URL implements an API.Accordingly, multiple APIs are aggregated under the same microservice.In one embodiment, the host portion of the URL identifies a tenant(e.g., https://tenant3.identity.oraclecloud.com:/oauth/v1/token”).

Configuring applications that integrate with external services with thenecessary endpoints and keeping that configuration up to date istypically a challenge. To meet this challenge, embodiments expose apublic discovery API at a well-known location from where applicationscan discover the information about IDCS they need in order to consumeIDCS APIs. In one embodiment, two discovery documents are supported:IDCS Configuration (which includes IDCS, SAML, SCIM, OAuth, and OpenIDConnect configuration, at e.g.,<IDCS-URL>/.well-known/idcs-configuration), and Industry-standard OpenIDConnect Configuration (at, e.g.,<IDCS-URL>/.well-known/openid-configuration). Applications can retrievediscovery documents by being configured with a single IDCS URL.

FIG. 6 is a block diagram providing a system view 600 of IDCS in oneembodiment. In FIG. 6, any one of a variety of applications/services 602may make HTTP calls to IDCS APIs to use IDCS services. Examples of suchapplications/services 602 are web applications, native applications(e.g., applications that are built to run on a specific operatingsystem, such as Windows applications, iOS applications, Androidapplications, etc.), web services, customer applications, partnerapplications, or any services provided by a public cloud, such asSoftware as a Service (“SaaS”), PaaS, and Infrastructure as a Service(“IaaS”).

In one embodiment, the HTTP requests of applications/services 602 thatrequire IDCS services go through an Oracle Public Cloud BIG-IP appliance604 and an IDCS BIG-IP appliance 606 (or similar technologies such as aLoad Balancer, or a component called a Cloud Load Balancer as a Service(“LBaaS”) that implements appropriate security rules to protect thetraffic). However, the requests can be received in any manner. At IDCSBIG-IP appliance 606 (or, as applicable, a similar technology such as aLoad Balancer or a Cloud LBaaS), a cloud provisioning engine 608performs tenant and service orchestration. In one embodiment, cloudprovisioning engine 608 manages internal security artifacts associatedwith a new tenant being on-boarded into the cloud or a new serviceinstance purchased by a customer.

The HTTP requests are then received by an IDCS web routing tier 610 thatimplements a security gate (i.e., Cloud Gate) and provides servicerouting and microservices registration and discovery 612. Depending onthe service requested, the HTTP request is forwarded to an IDCSmicroservice in the IDCS middle tier 614. IDCS microservices processexternal and internal HTTP requests. IDCS microservices implementplatform services and infrastructure services. IDCS platform servicesare separately deployed Java-based runtime services implementing thebusiness of IDCS. IDCS infrastructure services are separately deployedruntime services providing infrastructure support for IDCS. IDCS furtherincludes infrastructure libraries that are common code packaged asshared libraries used by IDCS services and shared libraries.Infrastructure services and libraries provide supporting capabilities asrequired by platform services for implementing their functionality.

Platform Services

In one embodiment, IDCS supports standard authentication protocols,hence IDCS microservices include platform services such as OpenIDConnect, OAuth, SAML2, System for Cross-domain Identity Management++(“SCIM++”), etc.

The OpenID Connect platform service implements standard OpenID ConnectLogin/Logout flows. Interactive web-based and native applicationsleverage standard browser-based OpenID Connect flow to request userauthentication, receiving standard identity tokens that are JavaScriptObject Notation (“JSON”) Web Tokens (“JWTs”) conveying the user'sauthenticated identity. Internally, the runtime authentication model isstateless, maintaining the user's authentication/session state in theform of a host HTTP cookie (including the JWT identity token). Theauthentication interaction initiated via the OpenID Connect protocol isdelegated to a trusted SSO service that implements the user login/logoutceremonies for local and federated logins. Further details of thisfunctionality are disclosed below with reference to FIGS. 10 and 11. Inone embodiment, OpenID Connect functionality is implemented accordingto, for example, OpenID Foundation standards.

The OAuth2 platform service provides token authorization services. Itprovides a rich API infrastructure for creating and validating accesstokens conveying user rights to make API calls. It supports a range ofuseful token grant types, enabling customers to securely connect clientsto their services. It implements standard 2-legged and 3-legged OAuth2token grant types. Support for OpenID Connect (“OIDC”) enables compliantapplications (OIDC relaying parties (“RP”s)) to integrate with IDCS asthe identity provider (OIDC OpenID provider (“OP”)). Similarly, theintegration of IDCS as OIDC RP with social OIDC OP (e.g., Facebook,Google, etc.) enables customers to allow social identities policy-basedaccess to applications. In one embodiment, OAuth functionality isimplemented according to, for example, Internet Engineering Task Force(“IETF”), Request for Comments (“RFC”) 6749.

The SAML2 platform service provides identity federation services. Itenables customers to set up federation agreements with their partnersbased on SAML identity provider (“IDP”) and SAML service provider (“SP”)relationship models. In one embodiment, the SAML2 platform serviceimplements standard SAML2 Browser POST Login and Logout Profiles. In oneembodiment, SAML functionality is implemented according to, for example,IETF, RFC 7522.

SCIM is an open standard for automating the exchange of user identityinformation between identity domains or information technology (“IT”)systems, as provided by, e.g., IETF, RFCs 7642, 7643, 7644. The SCIM++platform service provides identity administration services and enablescustomers to access IDP features of IDCS. The administration servicesexpose a set of stateless REST interfaces (i.e., APIs) that coveridentity lifecycle, password management, group management, etc.,exposing such artifacts as web-accessible resources.

All IDCS configuration artifacts are resources, and the APIs of theadministration services allow for managing IDCS resources (e.g., users,roles, password policies, applications, SAML/OIDC identity providers,SAML service providers, keys, certifications, notification templates,etc.). Administration services leverage and extend the SCIM standard toimplement schema-based REST APIs for Create, Read, Update, Delete, andQuery (“CRUDQ”) operations on all IDCS resources. Additionally, allinternal resources of IDCS used for administration and configuration ofIDCS itself are exposed as SCIM-based REST APIs. Access to the identitystore 618 is isolated to the SCIM++ API.

In one embodiment, for example, the SCIM standard is implemented tomanage the users and groups resources as defined by the SCIMspecifications, while SCIM++ is configured to support additional IDCSinternal resources (e.g., password policies, roles, settings, etc.)using the language defined by the SCIM standard.

The Administration service supports the SCIM 2.0 standard endpoints withthe standard SCIM 2.0 core schemas and schema extensions where needed.In addition, the Administration service supports several SCIM 2.0compliant endpoint extensions to manage other IDCS resources, forexample, Users, Groups, Applications, Settings, etc. The Administrationservice also supports a set of remote procedure call-style (“RPC-style”)REST interfaces that do not perform CRUDQ operations but instead providea functional service, for example, “UserPasswordGenerator,”“UserPasswordValidator,” etc.

IDCS Administration APIs use the OAuth2 protocol for authentication andauthorization. IDCS supports common OAuth2 scenarios such as scenariosfor web server, mobile, and JavaScript applications. Access to IDCS APIsis protected by access tokens. To access IDCS Administration APIs, anapplication needs to be registered as an OAuth2 client or an IDCSApplication (in which case the OAuth2 client is created automatically)through the IDCS Administration console and be granted desired IDCSAdministration Roles. When making IDCS Administration API calls, theapplication first requests an access token from the IDCS OAuth2 Service.After acquiring the token, the application sends the access token to theIDCS API by including it in the HTTP authorization header. Applicationscan use IDCS Administration REST APIs directly, or use an IDCS JavaClient API Library.

Infrastructure Services

The IDCS infrastructure services support the functionality of IDCSplatform services. These runtime services include an event processingservice (for asynchronously processing user notifications, applicationsubscriptions, and auditing to database); a job scheduler service (forscheduling and executing jobs, e.g., executing immediately or at aconfigured time long-running tasks that do not require userintervention); a cache management service; a storage management service(for integrating with a public cloud storage service); a reports service(for generating reports and dashboards); an SSO service (for managinginternal user authentication and SSO); a user interface (“UI”) service(for hosting different types of UI clients); and a service managerservice. Service manager is an internal interface between the OraclePublic Cloud and IDCS. Service manager manages commands issued by theOracle Public Cloud, where the commands need to be implemented by IDCS.For example, when a customer signs up for an account in a cloud storebefore they can buy something, the cloud sends a request to IDCS askingto create a tenant. In this case, service manager implements the cloudspecific operations that the cloud expects IDCS to support.

An IDCS microservice may call another IDCS microservice through anetwork interface (i.e., an HTTP request).

In one embodiment, IDCS may also provide a schema service (or apersistence service) that allows for using a database schema. A schemaservice allows for delegating the responsibility of managing databaseschemas to IDCS. Accordingly, a user of IDCS does not need to manage adatabase since there is an IDCS service that provides thatfunctionality. For example, the user may use the database to persistschemas on a per tenant basis, and when there is no more space in thedatabase, the schema service will manage the functionality of obtaininganother database and growing the space so that the users do not have tomanage the database themselves.

IDCS further includes data stores which are data repositoriesrequired/generated by IDCS, including an identity store 618 (storingusers, groups, etc.), a global database 620 (storing configuration dataused by IDCS to configure itself), an operational schema 622 (providingper tenant schema separation and storing customer data on a per customerbasis), an audit schema 624 (storing audit data), a caching cluster 626(storing cached objects to speed up performance), etc. All internal andexternal IDCS consumers integrate with the identity services overstandards-based protocols. This enables use of a domain name system(“DNS”) to resolve where to route requests, and decouples consumingapplications from understanding the internal implementation of identityservices.

Real-Time and Near-Real-Time Tasks

IDCS separates the tasks of a requested service into synchronousreal-time and asynchronous near-real-time tasks, where real-time tasksinclude only the operations that are needed for the user to proceed. Inone embodiment, a real-time task is a task that is performed withminimal delay, and a near-real-time task is a task that is performed inthe background without the user having to wait for it. In oneembodiment, a real-time task is a task that is performed withsubstantially no delay or with negligible delay, and appears to a useras being performed almost instantaneously.

The real-time tasks perform the main business functionality of aspecific identity service. For example, when requesting a login service,an application sends a message to authenticate a user's credentials andget a session cookie in return. What the user experiences is logginginto the system. However, several other tasks may be performed inconnection with the user's logging in, such as validating who the useris, auditing, sending notifications, etc. Accordingly, validating thecredentials is a task that is performed in real-time so that the user isgiven an HTTP cookie to start a session, but the tasks related tonotifications (e.g., sending an email to notify the creation of anaccount), audits (e.g., tracking/recording), etc., are near-real-timetasks that can be performed asynchronously so that the user can proceedwith least delay.

When an HTTP request for a microservice is received, the correspondingreal-time tasks are performed by the microservice in the middle tier,and the remaining near-real-time tasks such as operational logic/eventsthat are not necessarily subject to real-time processing are offloadedto message queues 628 that support a highly scalable asynchronous eventmanagement system 630 with guaranteed delivery and processing.Accordingly, certain behaviors are pushed from the front end to thebackend to enable IDCS to provide high level service to the customers byreducing latencies in response times. For example, a login process mayinclude validation of credentials, submission of a log report, updatingof the last login time, etc., but these tasks can be offloaded to amessage queue and performed in near-real-time as opposed to real-time.

In one example, a system may need to register or create a new user. Thesystem calls an IDCS SCIM API to create a user. The end result is thatwhen the user is created in identity store 618, the user gets anotification email including a link to reset their password. When IDCSreceives a request to register or create a new user, the correspondingmicroservice looks at configuration data in the operational database(located in global database 620 in FIG. 6) and determines that the“create user” operation is marked with a “create user” event which isidentified in the configuration data as an asynchronous operation. Themicroservice returns to the client and indicates that the creation ofthe user is done successfully, but the actual sending of thenotification email is postponed and pushed to the backend. In order todo so, the microservice uses a messaging API 616 to queue the message inqueue 628 which is a store.

In order to dequeue queue 628, a messaging microservice, which is aninfrastructure microservice, continually runs in the background andscans queue 628 looking for events in queue 628. The events in queue 628are processed by event subscribers 630 such as audit, user notification,application subscriptions, data analytics, etc. Depending on the taskindicated by an event, event subscribers 630 may communicate with, forexample, audit schema 624, a user notification service 634, an identityevent subscriber 632, etc. For example, when the messaging microservicefinds the “create user” event in queue 628, it executes thecorresponding notification logic and sends the corresponding email tothe user.

In one embodiment, queue 628 queues operational events published bymicroservices 614 as well as resource events published by APIs 616 thatmanage IDCS resources.

IDCS uses a real-time caching structure to enhance system performanceand user experience. The cache itself may also be provided as amicroservice. IDCS implements an elastic cache cluster 626 that grows asthe number of customers supported by IDCS scales. Cache cluster 626 maybe implemented with a distributed data grid which is disclosed in moredetail below. In one embodiment, write-only resources bypass cache.

In one embodiment, IDCS runtime components publish health andoperational metrics to a public cloud monitoring module 636 thatcollects such metrics of a public cloud such as Oracle Public Cloud fromOracle Corp.

In one embodiment, IDCS may be used to create a user. For example, aclient application 602 may issue a REST API call to create a user. Adminservice (a platform service in 614) delegates the call to a user manager(an infrastructure library/service in 614), which in turn creates theuser in the tenant-specific ID store stripe in ID store 618. On “UserCreate Success”, the user manager audits the operation to the audittable in audit schema 624, and publishes an“identity.user.create.success” event to message queue 628. Identitysubscriber 632 picks up the event and sends a “Welcome” email to thenewly created user, including newly created login details.

In one embodiment, IDCS may be used to grant a role to a user, resultingin a user provisioning action. For example, a client application 602 mayissue a REST API call to grant a user a role. Admin service (a platformservice in 614) delegates the call to a role manager (an infrastructurelibrary/service in 614), who grants the user a role in thetenant-specific ID store stripe in ID store 618. On “Role GrantSuccess”, the role manager audits the operations to the audit table inaudit schema 624, and publishes an “identity.user.role.grant.success”event to message queue 628. Identity subscriber 632 picks up the eventand evaluates the provisioning grant policy. If there is an activeapplication grant on the role being granted, a provisioning subscriberperforms some validation, initiates account creation, calls out thetarget system, creates an account on the target system, and marks theaccount creation as successful. Each of these functionalities may resultin publishing of corresponding events, such as“prov.account.create.initiate”, “prov.target.create.initiate”,“prov.target.create.success”, or “prov.account.create.success”. Theseevents may have their own business metrics aggregating number ofaccounts created in the target system over the last N days.

In one embodiment, IDCS may be used for a user to log in. For example, aclient application 602 may use one of the supported authentication flowsto request a login for a user. IDCS authenticates the user, and uponsuccess, audits the operation to the audit table in audit schema 624.Upon failure, IDCS audits the failure in audit schema 624, and publishes“login.user.login.failure” event in message queue 628. A loginsubscriber picks up the event, updates its metrics for the user, anddetermines if additional analytics on the user's access history need tobe performed.

Accordingly, by implementing “inversion of control” functionality (e.g.,changing the flow of execution to schedule the execution of an operationat a later time so that the operation is under the control of anothersystem), embodiments enable additional event queues and subscribers tobe added dynamically to test new features on a small user sample beforedeploying to broader user base, or to process specific events forspecific internal or external customers.

Stateless Functionality

IDCS microservices are stateless, meaning the microservices themselvesdo not maintain state. “State” refers to the data that an applicationuses in order to perform its capabilities. IDCS provides multi-tenantfunctionality by persisting all state into tenant specific repositoriesin the IDCS data tier. The middle tier (i.e., the code that processesthe requests) does not have data stored in the same location as theapplication code. Accordingly, IDCS is highly scalable, bothhorizontally and vertically.

To scale vertically (or scale up/down) means to add resources to (orremove resources from) a single node in a system, typically involvingthe addition of CPUs or memory to a single computer. Verticalscalability allows an application to scale up to the limits of itshardware. To scale horizontally (or scale out/in) means to add morenodes to (or remove nodes from) a system, such as adding a new computerto a distributed software application. Horizontal scalability allows anapplication to scale almost infinitely, bound only by the amount ofbandwidth provided by the network.

Stateless-ness of the middle tier of IDCS makes it horizontally scalablejust by adding more CPUs, and the IDCS components that perform the workof the application do not need to have a designated physicalinfrastructure where a particular application is running. Stateless-nessof the IDCS middle tier makes IDCS highly available, even when providingidentity services to a very large number of customers/tenants. Each passthrough an IDCS application/service is focused on CPU usage only toperform the application transaction itself but not use hardware to storedata. Scaling is accomplished by adding more slices when the applicationis running, while data for the transaction is stored at a persistencelayer where more copies can be added when needed.

The IDCS web tier, middle tier, and data tier can each scaleindependently and separately. The web tier can be scaled to handle moreHTTP requests. The middle tier can be scaled to support more servicefunctionality. The data tier can be scaled to support more tenants.

IDCS Functional View

FIG. 6A is an example block diagram 600 b of a functional view of IDCSin one embodiment. In block diagram 600 b, the IDCS functional stackincludes services, shared libraries, and data stores. The servicesinclude IDCS platform services 640 b, IDCS premium services 650 b, andIDCS infrastructure services 662 b. In one embodiment, IDCS platformservices 640 b and IDCS premium services 650 b are separately deployedJava-based runtime services implementing the business of IDCS, and IDCSinfrastructure services 662 b are separately deployed runtime servicesproviding infrastructure support for IDCS. The shared libraries includeIDCS infrastructure libraries 680 b which are common code packaged asshared libraries used by IDCS services and shared libraries. The datastores are data repositories required/generated by IDCS, includingidentity store 698 b, global configuration 700 b, message store 702 b,global tenant 704 b, personalization settings 706 b, resources 708 b,user transient data 710 b, system transient data 712 b, per-tenantschemas (managed ExaData) 714 b, operational store (not shown), cachingstore (not shown), etc.

In one embodiment, IDCS platform services 640 b include, for example,OpenID Connect service 642 b, OAuth2 service 644 b, SAML2 service 646 b,and SCIM++ service 648 b. In one embodiment, IDCS premium servicesinclude, for example, cloud SSO and governance 652 b, enterprisegovernance 654 b, AuthN broker 656 b, federation broker 658 b, andprivate account management 660 b.

IDCS infrastructure services 662 b and IDCS infrastructure libraries 680b provide supporting capabilities as required by IDCS platform services640 b to do their work. In one embodiment, IDCS infrastructure services662 b include job scheduler 664 b, UI 666 b, SSO 668 b, reports 670 b,cache 672 b, storage 674 b, service manager 676 b (public cloudcontrol), and event processor 678 b (user notifications, appsubscriptions, auditing, data analytics). In one embodiment, IDCSinfrastructure libraries 680 b include data manager APIs 682 b, eventAPIs 684 b, storage APIs 686 b, authentication APIs 688 b, authorizationAPIs 690 b, cookie APIs 692 b, keys APIs 694 b, and credentials APIs 696b. In one embodiment, cloud compute service 602 b (internal Nimbula)supports the function of IDCS infrastructure services 662 b and IDCSinfrastructure libraries 680 b.

In one embodiment, IDCS provides various UIs 602 b for a consumer ofIDCS services, such as customer end user UI 604 b, customer admin UI 606b, DevOps admin UI 608 b, and login UI 610 b. In one embodiment, IDCSallows for integration 612 b of applications (e.g., customer apps 614 b,partner apps 616 b, and cloud apps 618 b) and firmware integration 620b. In one embodiment, various environments may integrate with IDCS tosupport their access control needs. Such integration may be provided by,for example, identity bridge 622 b (providing AD integration, WNA, andSCIM connector), Apache agent 624 b, or MSFT agent 626 b.

In one embodiment, internal and external IDCS consumers integrate withthe identity services of IDCS over standards-based protocols 628 b, suchas OpenID Connect 630 b, OAuth2 632 b, SAML2 634 b, SCIM 636 b, andREST/HTTP 638 b. This enables use of a domain name system (“DNS”) toresolve where to route requests, and decouples the consumingapplications from understanding internal implementation of the identityservices.

The IDCS functional view in FIG. 6A further includes public cloudinfrastructure services that provide common functionality that IDCSdepends on for user notifications (cloud notification service 718 b),file storage (cloud storage service 716 b), and metrics/alerting forDevOps (cloud monitoring service (EM) 722 b and cloud metrics service(Graphite) 720 b).

Cloud Gate

In one embodiment, IDCS implements a “Cloud Gate” in the web tier. Inone embodiment, Cloud Gate is implemented by a web server plugin thatenables web applications to externalize user SSO to an identitymanagement system (e.g., IDCS), similar to WebGate or WebAgenttechnologies that work with enterprise IDM stacks. In one embodiment,Cloud Gate acts as a security gatekeeper that secures access to IDCSAPIs. In one embodiment, Cloud Gate is implemented by a web/proxy serverplugin that provides a web Policy Enforcement Point (“PEP”) forprotecting HTTP resources based on OAuth. In one embodiment, Cloud Gatealso performs authentication (e.g., OAuth authentication).

In one embodiment, Cloud Gate may be deployed to protect a single-tenantapplication or a multi-tenant application, and may be deployed inproxy-mode front-ending different types of applications. In oneembodiment, Cloud Gate supports single-tenant and multi-tenantapplications by using respective default configurations for <Tenant>(represents what tenant owns the Cloud Gate instance) and <HostIdentifier> (represents what application is being accessed). In oneembodiment, local configurations specify default values for theseartifacts, and may be overwritten on a per-request basis via HTTPheaders supplied by the routing tier. For example, for a multi-tenantapplication, <Tenant> defines Cloud Gate's tenancy and is used toconstruct IDCS service URLs when contacting an IDCS server, and may beoverwritten on a per-request basis by an optionalX-RESOURCE-IDENTITY-DOMAIN-NAME header including <tenant-name> (e.g.,“acme”). Further, for a multi-tenant application, <Host Identifier>defines the cookie domain and is used for managing local sessioncookies, and may be overwritten on a per-request basis by an optional“host” header supplied by the client or the routing tier (e.g.,“acme.pcs1.dc4.oraclecloud.com”).

In one embodiment, one instance of Cloud Gate is deployed for eachtenant. However, in alternative embodiments, there may be multipleinstances of Cloud Gate deployed for a tenant, for example, in ahigh-availability cluster of servers providing replication and failover.In one embodiment, Cloud Gate provides a multi-tenant mode that allows asingle Cloud Gate instance to support multiple tenants, for example,when an “infrastructure” Cloud Gate is in front of IDCS itself (ratherthan in front of a tenant's application) and handles requests frommultiple tenants before passing them on to IDCS services.

In one embodiment, Cloud Gate supports multi-tenancy by determining aparticular tenant from the header values of the requests that are passedto it. Cloud Gate substitutes the tenancies in various URLs, and usesthe URLs to look up application/host specific policies. Cloud Gateapplies those policies for the request, and uses that information topass along the request to the appropriate components of IDCS.

In one embodiment, the tenant indicated in the incoming request is notsubstituted (i.e., the incoming request is not modified), but used inrequests made by Cloud Gate itself to IDCS services (e.g., policylookups, credential validation, etc.). In one embodiment, Cloud Gate isprovisioned with URLs for IDCS services, and these URLs may haveplaceholders for a tenant (e.g., “http://%tenant%.idcs.oracle.com”) ormay indicate the Cloud Gate's tenant. In this embodiment, theplaceholder or the Cloud Gate's tenant is replaced with the tenantindicated in the incoming request so that a request by Cloud Gate to anIDCS service is made using the tenant specified in the incoming request.

For example, Cloud Gate may be protecting a docketing application in anenterprise cloud. The application may belong to the IDCS service that isbeing requested (e.g., may be an application developed by IDCS such astenant-specific or user-specific administrative consoles) or may bedeveloped by a tenant of IDCS. The docketing application may be used bymultiple customers corresponding to respective tenants of IDCS. When acustomer needs to access the application, it sends a request to IDCS,and the tenancy of the customer is indicated in the header of therequest. Cloud Gate infers the tenancy from the request and looks up theparticular policy that needs to be applied for that tenancy. Cloud Gatethen applies the policy to that request, and if the policy allows therequest to go through, then Cloud Gate asserts the tenancy and allowsthe request to reach the docketing application. In one embodiment, CloudGate asserts the tenancy by adding a header to the request with thetenant name, and the request is then forwarded on to the origin server.In one embodiment, Cloud Gate may only assert some of the tenants inthis way, and the headers for the other tenants may already be presentin the request or may have been added by a previous load-balancingserver.

In one embodiment, a policy dictates if access to a particular resourceidentified through a request endpoint is allowed and what particularmethod of access is allowed to gain access to the resource. In oneembodiment, for example, “/admin/v1/HTTPAuthenticator” is the endpointfor validating user credentials for browser-based HTTP Basicauthentication, and the resource in this case is a credential validationservice. In one embodiment, for example, a public access policy for atenant may indicate that anyone in that tenant can access a resource(e.g., “/ui/v1/signin” which is the publicly-visible endpoint for thelogin page, “/ui/v1/pwdmustchange” and “/ui/v1/resetpwd” for passwordchange and reset pages, etc.). When a public access policy for a tenantindicates that anyone in that tenant can access a resource, Cloud Gateallows any request for accessing that resource from that tenancy to getthrough. Another policy may require that a user needs to supply ausername and password in order to access a resource (e.g., based onBasic Authentication), and the username and password are validatedagainst an identity. A further policy may require token basedauthentication based on OAuth, in which case the resource requires anOAuth access token to be provided by a user or programmatic applicationto gain access to the resource in the backend. For example, a user mayinitiate an OpenID flow to obtain an OAuth access token to gain accessto a resource, or a client application may gain programmatic access tothe resource by obtaining the token ahead of time and then providing thetoken along with their credentials to gain access to the resource.

In one embodiment, the policies are specified in a file managed by theCloud Gate. In one embodiment, the file is stored locally at the CloudGate. In an alternative or additional embodiment, the file may be storedon the server side within IDCS (e.g., in a policy store).

FIG. 7 is a block diagram 700 of an embodiment that implements a CloudGate 702 running in a web server 712 and acting as a Policy EnforcementPoint (“PEP”) configured to integrate with IDCS Policy Decision Point(“PDP”) using open standards (e.g., OAuth2, OpenID Connect, etc.) whilesecuring access to web browser and REST API resources 714 of anapplication. In some embodiments, the PDP is implemented at OAuth and/orOpenID Connect microservices 704 of IDCS.

In the embodiment of FIG. 7, a program or application client 708 may beattempting to access resources 714 protected by Cloud Gate 702, or anend user 710 may use a web browser 706 on their computer to accessresources 714 protected by Cloud Gate 702. In one embodiment, Cloud Gate702 may implement different functionalities for protecting resources714, depending on whether resources 714 are being accessed by end user710 or programmatic application client 708.

In one embodiment, when a user browser 706 sends a request to IDCS for alogin of a user 710, a corresponding IDCS PDP validates the credentialsand then decides whether the credentials are sufficient (e.g., whetherto request for further credentials such as a second password). In theembodiment of FIG. 7, Cloud Gate 702 may act both as the PEP and as thePDP since it has a local session. In one embodiment, Cloud Gate acts asa PEP by handling policy enforcement and determining how (or if) theuser has to be authenticated, and the PDP handles the actualauthentication. In one embodiment, Cloud Gate can act as a PDP if noauthentication is required (e.g., via “public” policy) or if CloudGate's session cookie is present and validating the cookie can be doneinstead of validating credentials.

In one embodiment, for example, in order to access resource 714, user710 may type in a corresponding URL in browser 706. Browser 706 takesuser 710 to web server 712. Cloud Gate 702 then loads the correspondingpolicy. If the policy indicates that resource 714 is protected, CloudGate 702 initiates any required authentication process. In oneembodiment, Cloud Gate 702 does not directly challenge the user (i.e.,it is not responsible for any UI), but once the user is challenged forauthentication, Cloud Gate 702 validates user credentials (e.g., forBasic Auth). For example, when user 710 enters their username andpassword, Cloud Gate 702 sends the username and password to acorresponding microservice 704 in IDCS (e.g., OAuth2) to authenticateuser 710. If the authentication is performed successfully, Cloud Gate702 allows user 710 to access resource 714.

In one embodiment, Cloud Gate 702 acts as an HTTP Basic Authauthenticator, validating HTTP Basic Auth credentials against IDCS. Thisbehavior is supported in both session-less and session-based (localsession cookie) modes. No server-side IDCS session is created in thiscase. For HTTP Basic Authentication, Cloud Gate 702 returns an HTTP“unauthorized” status code to the browser, which in response displays adialog prompting for username/password. Those credentials are submittedto Cloud Gate 702, which authenticates them against IDCS.

In one embodiment, for authentication according to OAuth, Cloud Gate 702returns an HTTP redirect status code, which directs the browser to theOAuth microservice, which, together with the SSO microservice, handlesthe actual login flow, including displaying the login page in thebrowser and authenticating the credentials provided by the user. Duringweb browser-based user access, Cloud Gate 702 acts as an OIDC RP 718initiating a user authentication flow. If user 710 has no valid localuser session, Cloud Gate 702 re-directs the user to the SSO microserviceand participates in the OIDC “Authorization Code” flow with the SSOmicroservice. The flow concludes with the delivery of a JWT as anidentity token. Cloud Gate 708 validates the JWT (e.g., looks atsignature, expiration, destination/audience, etc.) and issues a localsession cookie for user 710. It acts as a session manager 716 securingweb browser access to protected resources and issuing, updating, andvalidating the local session cookie. It also provides a logout URL forremoval of its local session cookie.

In one embodiment, for example, in order to access resource 714protected by Cloud Gate 702, a programmatic application client 708 makesa corresponding request to web server 712, and along with that request,application client 708 sends an OAuth token. Cloud Gate 702 receives thetoken and connects to the OAuth service 704 to validate the OAuth tokenagainst OAuth2 service 704. Once the token is validated, Cloud Gate 702allows application client 708 to access the protected resource 714.

In one embodiment, application client 708 may obtain the token in apre-registration process (e.g., performed by an administrator). In thepre-registration process, application client 708 registers itself inIDCS as a trusted application that is allowed to access protectedresources 714. The token may be generated by the IDCS OAuthmicroservice.

As part of one-time deployment, Cloud Gate 702 is registered with IDCSas an OAuth2 client, enabling it to request OIDC and OAuth2 operationsagainst IDCS. Thereafter, it maintains configuration information aboutan application's protected and unprotected resources, subject to requestmatching rules (how to match URLs, e.g., with wild cards, regularexpressions, etc.). Cloud Gate 702 can be deployed to protect differentapplications having different security policies, and the protectedapplications can be multi-tenant.

During programmatic access by REST API clients 708, Cloud Gate 702 mayact as an OAuth2 resource server/filter 720 for an application'sprotected REST APIs 714. It checks for the presence of a request with anauthorization header and an access token. When client 708 (e.g., mobile,web apps, JavaScript, etc.) presents an access token (issued by IDCS) touse with a protected REST API 714, Cloud Gate 702 validates the accesstoken before allowing access to the API (e.g., signature, expiration,audience, etc.). The original access token is passed along unmodified.

FIG. 7A is an example block diagram 700B illustrating how a Cloud Gate702B handles host identifiers. Each host identifier represents a logicalweb domain associated with an application protected by Cloud Gate 702B.In the example embodiment of FIG. 7A, a general format for the URLsreceived by a Routing Tier as a Service (“RTaaS”) 704B is:

https://<tenant>.<service>.<dc>.oraclecloud.com/<resource>

identifying the tenancy at the beginning (<tenant>), then a service(<service>), the data center (<dc>), the root domain(<oraclecloud.com>), and a resource API endpoint at the end(<resource>). In one embodiment, at runtime during request processing,Cloud Gate 702B uses the host identifier supplied by the client or therouting tier (i.e., RTaaS 704B) via the “host” header. If no hostidentifier is available from the routing tier or no match is found, thenCloud Gate 702B constructs the host identifier from its own “<defaulthost identifier>”. In one embodiment, more than one host identifiers maybe used by the IDCS routing tier for an application, and each requestpassing through Cloud Gate 702B is processed in the context of therespective host identifier, including scoping of the local sessioncookie and resolving the access policy file. For example, when CloudGate 702B receives a URL, it looks at the corresponding host identifierand determines what policy needs to be applied.

In one embodiment, RTaaS 704B has multiple physical web proxies, eachhaving a physical Cloud Gate 702B defined in the RTaaS IDCS account708B. Each web proxy and its corresponding Cloud Gate 702B support anumber of virtual hosts (e.g., between 1 to 30000 virtual hosts). Eachvirtual host represents a web tier per service instance 706B as assignedby RTaaS 704B. On each request, RTaaS 704B sets a header with the nameof the virtual host (e.g., “coke.docs.dc4.oraclecloud.com”,“pepsi.mcs.dc4.oraclecloud.com”, “intel.pcs.dc4.oraclecloud.com”, etc.).In one embodiment, session cookies at Cloud Gate 702B are scoped to avirtual host, and proper re-entrance functionality is implemented. Forexample, Cloud Gate 702B may receive AZ code on a “redirect_uri”endpoint 714B to set a cookie, and may receive a request on a“logout_uri” endpoint 712B to clear a cookie.

In one embodiment, each physical Cloud Gate instance exposes acorresponding fixed “redirect_uri” endpoint 714B and a correspondingfixed “logout_uri” endpoint 712B that are defined in the OAuth profileregistered for that Cloud Gate instance. The URIs are used ininteractions between Cloud Gate 702B and OIDC. In one embodiment, OIDCvalidates the “redirect_uri” parameter against known redirect URIs forthe Cloud Gate from which the request is originating. In one embodiment,a match does not have to be “exact” in terms of comparing string values,but it has to satisfy the condition that it is the same physicalinstance of the Cloud Gate regardless of the matching algorithm. In oneembodiment, the “logout_uri” is saved in IDCS 710B as part of therespective Cloud Gate's registered OAuth profile, and that Cloud Gatedoes not pass the “logout_uri” to the server in any of its interactions.When fully constructed, the “redirect_uri” and the “logout_uri” areassumed to include a tenant template and are translated prior to use bythe respective Cloud Gate 702B and by OIDC.

In one embodiment, the interactions between Cloud Gate 702B and IDCSservers 7106 treat the combination of the physical Cloud Gate 702B andthe host identifier as one logical OAuth RP. In the operations initiatedby Cloud Gate 702B to IDCS OIDC microservice, and by IDCS OIDCmicroservice to Cloud Gate 702B, the host identifier is sent via the“X-HOST-IDENTIFIER-NAME” query string parameter. When invokinglogin/logout requests by Cloud Gate 702B, the host identifier querystring parameter is sent by Cloud Gate 702B from the host identifierheader it received from the client or the routing tier. When trackingthe RP in the request cookie created by IDCS OIDC microservice, thevalue of the host identifier query string parameter is saved per RP inthe request cookie. When invoking the RP's “redirect_uri” and“logout_uri” by IDCS OIDC microservice, the host identifier query stringparameter is sent by IDCS OIDC microservice from the host identifiervalue saved in the request cookie.

Generally, OAuth is used to generate either a client identitypropagation token (e.g., indicating who the client is) or a useridentity propagation token (e.g., indicating who the user is). In theembodiments, the implementation of OAuth in Cloud Gate is based on a JWTwhich defines a format for web tokens, as provided by, e.g., IETF, RFC7519.

When a user logs in, a JWT is issued. The JWT is signed by IDCS andsupports multi-tenant functionality in IDCS. Cloud Gate validates theJWT issued by IDCS to allow for multi-tenant functionality in IDCS.Accordingly, IDCS provides multi-tenancy in the physical structure aswell as in the logical business process that underpins the securitymodel.

Tenancy Types

IDCS specifies three types of tenancies: customer tenancy, clienttenancy, and user tenancy. Customer or resource tenancy specifies whothe customer of IDCS is (i.e., for whom is the work being performed).Client tenancy specifies which client application is trying to accessdata (i.e., what application is doing the work). User tenancy specifieswhich user is using the application to access data (i.e., by whom is thework being performed). For example, when a professional services companyprovides system integration functionality for a warehouse club and usesIDCS for providing identity management for the warehouse club systems,user tenancy corresponds to the professional services company, clienttenancy is the application that is used to provide system integrationfunctionality, and customer tenancy is the warehouse club.

Separation and identification of these three tenancies enablesmulti-tenant functionality in a cloud-based service. Generally, foron-premise software that is installed on a physical machine on-premise,there is no need to specify three different tenancies since a user needsto be physically on the machine to log in. However, in a cloud-basedservice structure, embodiments use tokens to determine who is using whatapplication to access which resources. The three tenancies are codifiedby tokens, enforced by Cloud Gate, and used by the business services inthe middle tier. In one embodiment, an OAuth server generates thetokens. In various embodiments, the tokens may be used in conjunctionwith any security protocol other than OAuth.

Decoupling user, client, and resource tenancies provides substantialbusiness advantages for the users of the services provided by IDCS. Forexample, it allows a service provider that understands the needs of abusiness (e.g., a healthcare business) and their identity managementproblems to buy services provided by IDCS, develop their own backendapplication that consumes the services of IDCS, and provide the backendapplications to the target businesses. Accordingly, the service providermay extend the services of IDCS to provide their desired capabilitiesand offer those to certain target businesses. The service provider doesnot have to build and run software to provide identity services but caninstead extend and customize the services of IDCS to suit the needs ofthe target businesses.

Some known systems only account for a single tenancy which is customertenancy. However, such systems are inadequate when dealing with accessby a combination of users such as customer users, customer's partners,customer's clients, clients themselves, or clients that customer hasdelegated access to. Defining and enforcing multiple tenancies in theembodiments facilitates the identity management functionality over suchvariety of users.

In one embodiment, one entity of IDCS does not belong to multipletenants at the same time; it belongs to only one tenant, and a “tenancy”is where artifacts live. Generally, there are multiple components thatimplement certain functions, and these components can belong to tenantsor they can belong to infrastructure. When infrastructure needs to acton behalf of tenants, it interacts with an entity service on behalf ofthe tenant. In that case, infrastructure itself has its own tenancy andcustomer has its own tenancy. When a request is submitted, there can bemultiple tenancies involved in the request.

For example, a client that belongs to “tenant 1” may execute a requestto get a token for “tenant 2” specifying a user in “tenant 3.” Asanother example, a user living in “tenant 1” may need to perform anaction in an application owned by “tenant 2”. Thus, the user needs to goto the resource namespace of “tenant 2” and request a token forthemselves. Accordingly, delegation of authority is accomplished byidentifying “who” can do “what” to “whom.” As yet another example, afirst user working for a first organization (“tenant 1”) may allow asecond user working for a second organization (“tenant 2”) to haveaccess to a document hosted by a third organization (“tenant 3”).

In one example, a client in “tenant 1” may request an access token for auser in “tenant 2” to access an application in “tenant 3”. The clientmay do so by invoking an OAuth request for the token by going to“http://tenant3/oauth/token”. The client identifies itself as a clientthat lives in “tenant 1” by including a “client assertion” in therequest. The client assertion includes a client ID (e.g., “client 1”)and the client tenancy “tenant 1”. As “client 1” in “tenant 1”, theclient has the right to invoke a request for a token on “tenant 3”, andthe client wants the token for a user in “tenant 2”. Accordingly, a“user assertion” is also passed as part of the same HTTP request toidentify “tenant 2” as the tenancy of the user, and a header of therequest identifies “tenant 3” as the tenancy of theresource/application. As a result, the request identifies the tenancy ofthe client, the tenancy of the user, and the tenancy of the resource.The access token that is generated will be issued in the context of thetarget tenancy which is the application tenancy (“tenant 3”) and willinclude the user tenancy (“tenant 2”). Accordingly, the access tokenidentifies the tenancy of the resource/application and the tenancy ofthe user.

In one embodiment, in the data tier, each tenant is implemented as aseparate stripe. From a data management perspective, artifacts live in atenant. From a service perspective, a service knows how to work withdifferent tenants, and the multiple tenancies are different dimensionsin the business function of a service. FIG. 8 illustrates an examplesystem 800 implementing multiple tenancies in an embodiment. System 800includes a client 802 that requests a service provided by a microservice804 that understands how to work with data in a database 806. Database806 includes multiple tenants 808 and each tenant includes the artifactsof the corresponding tenancy. In one embodiment, microservice 804 is anOAuth microservice requested through https://tenant3/oauth/token by aclient in “tenant 1” for getting a token for a user in “tenant 2” toaccess an application in “tenant 3”, and database 806 stores data of thetenancy of the client (“tenant 1”), the tenancy of the user (“tenant2”), and the tenancy of the resource/application (“tenant 3”). Thefunction of the OAuth microservice is performed in microservice 804using data from database 806 to verify that the request of client 802 islegitimate, and if it is legitimate, use the data from differenttenancies 808 to construct the token. Accordingly, system 800 ismulti-tenant in that it can work in a cross-tenant environment by notonly supporting services coming into each tenancy, but also supportingservices that can act on behalf of different tenants.

System 800 is advantageous since microservice 804 is physicallydecoupled from the data in database 806, and by replicating the dataacross locations that are closer to the client, microservice 804 can beprovided as a local service to the clients and system 800 can manage theavailability of the service and provide it globally.

In one embodiment, microservice 804 is stateless, meaning that themachine that runs microservice 804 does not maintain any markerspointing the service to any specific tenants. Instead, a tenancy may bemarked, for example, on the host portion of a URL of a request thatcomes in. That tenancy points to one of tenants 808 in database 806.When supporting a large number of tenants (e.g., millions of tenants),microservice 804 cannot have the same number of connections to database806, but instead uses a connection pool 810 which provides the actualphysical connections to database 806 in the context of a database user.Generally, connections are built by supplying an underlying driver orprovider with a connection string, which is used to address a specificdatabase or server and to provide instance and user authenticationcredentials (e.g., “Server=sql_box;Database=Common;UserID=uid;Pwd=password;”). Once a connection has been built, it can beopened and closed, and properties (e.g., the command time-out length, ortransaction, if one exists) can be set. The connection string includes aset of key-value pairs, dictated by the data access interface of thedata provider. A connection pool is a cache of database connectionsmaintained so that the connections can be reused when future requests toa database are required. In connection pooling, after a connection iscreated, it is placed in the pool and it is used again so that a newconnection does not have to be established. For example, when thereneeds to be ten connections between microservice 804 and database 808,there will be ten open connections in connection pool 810, all in thecontext of a database user (e.g., in association with a specificdatabase user, e.g., who is the owner of that connection, whosecredentials are being validated, is it a database user, is it a systemcredential, etc.).

The connections in connection pool 810 are created for a system userthat can access anything. Therefore, in order to correctly handleauditing and privileges by microservice 804 processing requests onbehalf of a tenant, the database operation is performed in the contextof a “proxy user” 812 associated with the schema owner assigned to thespecific tenant. This schema owner can access only the tenancy that theschema was created for, and the value of the tenancy is the value of theschema owner. When a request is made for data in database 806,microservice 804 uses the connections in connection pool 810 to providethat data. Accordingly, multi-tenancy is achieved by having stateless,elastic middle tier services process incoming requests in the context of(e.g., in association with) the tenant-specific data store bindingestablished on a per request basis on top of the data connection createdin the context of (e.g., in association with) the data store proxy userassociated with the resource tenancy, and the database can scaleindependently of the services.

The following provides an example functionality for implementing proxyuser 812:

dbOperation=<prepare DB command to execute>

dbConnection=getDBConnectionFromPool( )

dbConnection.setProxyUser (resourceTenant)

result=dbConnection.executeOperation (dbOperation)

In this functionality, microservice 804 sets the “Proxy User” setting onthe connection pulled from connection pool 810 to the “Tenant,” andperforms the database operation in the context of the tenant while usingthe database connection in connection pool 810.

When striping every table to configure different columns in a samedatabase for different tenants, one table may include all tenants' datamixed together. In contrast, one embodiment provides a tenant-drivendata tier. The embodiment does not stripe the same database fordifferent tenants, but instead provides a different physical databaseper tenant. For example, multi-tenancy may be implemented by using apluggable database (e.g., Oracle Database 12c from Oracle Corp.) whereeach tenant is allocated a separate partition. At the data tier, aresource manager processes the request and then asks for the data sourcefor the request (separate from metadata). The embodiment performsruntime switch to a respective data source/store per request. Byisolating each tenant's data from the other tenants, the embodimentprovides improved data security.

In one embodiment, various tokens codify different tenancies. A URLtoken may identify the tenancy of the application that requests aservice. An identity token may codify the identity of a user that is tobe authenticated. An access token may identify multiple tenancies. Forexample, an access token may codify the tenancy that is the target ofsuch access (e.g., an application tenancy) as well as the user tenancyof the user that is given access. A client assertion token may identifya client ID and the client tenancy. A user-assertion token may identifythe user and the user tenancy.

In one embodiment, an identity token includes at least a “claim” [asused by one of ordinary skill in the security field] indicating the usertenant name (i.e., where the user lives). A “claim” in connection withauthorization tokens is a statement that one subject makes about itselfor another subject. The statement can be about a name, identity, key,group, privilege, or capability, for example. Claims are issued by aprovider, and they are given one or more values and then packaged insecurity tokens that are issued by an issuer, commonly known as asecurity token service (“STS”).

In one embodiment, an access token includes at least a claim/statementindicating the resource tenant name at the time the request for theaccess token was made (e.g., the customer), a claim/statement indicatingthe user tenant name, a claim/statement indicating the name of the OAuthclient making the request, and a claim/statement indicating the clienttenant name.

In one embodiment, an access token may be implemented according to thefollowing JSON functionality:

{  ...  ″ tok_type ″ : ″AT″,  ″user_id″ : ″testuser″,  ″user_tenantname″: ″<value-of-identity-tenant>″  “tenant” : “<value-of-resource-tenant>” “client_id” : “testclient”,  “client_tenantname”:“<value-of-client-tenant>”  ... }

In one embodiment, a client assertion token includes at least aclaim/statement indicating the client tenant name, and a claim/statementindicating the name of the OAuth client making the request.

The tokens and/or multiple tenancies described herein may be implementedin any multi-tenant cloud-based service other than IDCS. For example,the tokens and/or multiple tenancies described herein may be implementedin SaaS or Enterprise Resource Planning (“ERP”) services.

FIG. 9 is a block diagram of a network view 900 of IDCS in oneembodiment. FIG. 9 illustrates network interactions that are performedin one embodiment between application “zones” 904. Applications arebroken into zones based on the required level of protection and theimplementation of connections to various other systems (e.g., SSL zone,no SSL zone, etc.). Some application zones provide services that requireaccess from the inside of IDCS, while some application zones provideservices that require access from the outside of IDCS, and some are openaccess. Accordingly, a respective level of protection is enforced foreach zone.

In the embodiment of FIG. 9, service to service communication isperformed using HTTP requests. In one embodiment, IDCS uses the accesstokens described herein not only to provide services but also to secureaccess to and within IDCS itself. In one embodiment, IDCS microservicesare exposed through RESTful interfaces and secured by the tokensdescribed herein.

In the embodiment of FIG. 9, any one of a variety ofapplications/services 902 may make HTTP calls to IDCS APIs to use IDCSservices. In one embodiment, the HTTP requests of applications/services902 go through an Oracle Public Cloud Load Balancing External Virtual IPaddress (“VIP”) 906 (or other similar technologies), a public cloud webrouting tier 908, and an IDCS Load Balancing Internal VIP appliance 910(or other similar technologies), to be received by IDCS web routing tier912. IDCS web routing tier 912 receives the requests coming in from theoutside or from the inside of IDCS and routes them across either an IDCSplatform services tier 914 or an IDCS infrastructure services tier 916.IDCS platform services tier 914 includes IDCS microservices that areinvoked from the outside of IDCS, such as OpenID Connect, OAuth, SAML,SCIM, etc. IDCS infrastructure services tier 916 includes supportingmicroservices that are invoked from the inside of IDCS to support thefunctionality of other IDCS microservices. Examples of IDCSinfrastructure microservices are UI, SSO, reports, cache, job scheduler,service manager, functionality for making keys, etc. An IDCS cache tier926 supports caching functionality for IDCS platform services tier 914and IDCS infrastructure services tier 916.

By enforcing security both for outside access to IDCS and within IDCS,customers of IDCS can be provided with outstanding security compliancefor the applications they run.

In the embodiment of FIG. 9, other than the data tier 918 whichcommunicates based on Structured Query Language (“SQL”) and the ID storetier 920 that communicates based on LDAP, OAuth protocol is used toprotect the communication among IDCS components (e.g., microservices)within IDCS, and the same tokens that are used for securing access fromthe outside of IDCS are also used for security within IDCS. That is, webrouting tier 912 uses the same tokens and protocols for processing therequests it receives regardless of whether a request is received fromthe outside of IDCS or from the inside of IDCS. Accordingly, IDCSprovides a single consistent security model for protecting the entiresystem, thereby allowing for outstanding security compliance since thefewer security models implemented in a system, the more secure thesystem is.

In the IDCS cloud environment, applications communicate by makingnetwork calls. The network call may be based on an applicable networkprotocol such as HTTP, Transmission Control Protocol (“TCP”), UserDatagram Protocol (“UDP”), etc. For example, an application X maycommunicate with an application Y based on HTTP by exposing applicationY as an HTTP Uniform Resource Locator (“URL”). In one embodiment, Y isan IDCS microservice that exposes a number of resources eachcorresponding to a capability. When X (e.g., another IDCS microservice)needs to call Y, it constructs a URL that includes Y and theresource/capability that needs to be invoked (e.g.,https:/host/Y/resource), and makes a corresponding REST call which goesthrough web routing tier 912 and gets directed to Y.

In one embodiment, a caller outside the IDCS may not need to know whereY is, but web routing tier 912 needs to know where application Y isrunning. In one embodiment, IDCS implements discovery functionality(implemented by an API of OAuth service) to determine where eachapplication is running so that there is no need for the availability ofstatic routing information.

In one embodiment, an enterprise manager (“EM”) 922 provides a “singlepane of glass” that extends on-premise and cloud-based management toIDCS. In one embodiment, a “Chef” server 924 which is a configurationmanagement tool from Chef Software, Inc., provides configurationmanagement functionality for various IDCS tiers. In one embodiment, aservice deployment infrastructure and/or a persistent stored module 928may send OAuth2 HTTP messages to IDCS web routing tier 912 for tenantlifecycle management operations, public cloud lifecycle managementoperations, or other operations. In one embodiment, IDCS infrastructureservices tier 916 may send ID/password HTTP messages to a public cloudnotification service 930 or a public cloud storage service 932.

Cloud Access Control—SSO

One embodiment supports lightweight cloud standards for implementing acloud scale SSO service. Examples of lightweight cloud standards areHTTP, REST, and any standard that provides access through a browser(since a web browser is lightweight). On the contrary, SOAP is anexample of a heavy cloud standard which requires more management,configuration, and tooling to build a client with. The embodiment usesOpenID Connect semantics for applications to request user authenticationagainst IDCS. The embodiment uses lightweight HTTP cookie-based usersession tracking to track user's active sessions at IDCS withoutstatefull server-side session support. The embodiment uses JWT-basedidentity tokens for applications to use in mapping an authenticatedidentity back to their own local session. The embodiment supportsintegration with federated identity management systems, and exposes SAMLIDP support for enterprise deployments to request user authenticationagainst IDCS.

FIG. 10 is a block diagram 1000 of a system architecture view of SSOfunctionality in IDCS in one embodiment. The embodiment enables clientapplications to leverage standards-based web protocols to initiate userauthentication flows. Applications requiring SSO integration with acloud system may be located in enterprise data centers, in remotepartner data centers, or even operated by a customer on-premise. In oneembodiment, different IDCS platform services implement the business ofSSO, such as OpenID Connect for processing login/logout requests fromconnected native applications (i.e., applications utilizing OpenIDConnect to integrate with IDCS); SAML IDP service for processingbrowser-based login/logout requests from connected applications; SAML SPservice for orchestrating user authentication against an external SAMLIDP; and an internal IDCS SSO service for orchestrating end user loginceremony including local or federated login flows, and for managing IDCShost session cookie. Generally, HTTP works either with a form or withouta form. When it works with a form, the form is seen within a browser.When it works without a form, it functions as a client to servercommunication. Both OpenID Connect and SAML require the ability torender a form, which may be accomplished by presence of a browser orvirtually performed by an application that acts as if there is abrowser. In one embodiment, an application client implementing userauthentication/SSO through IDCS needs to be registered in IDCS as anOAuth2 client and needs to obtain client identifier and credentials(e.g., ID/password, ID/certificate, etc.).

The example embodiment of FIG. 10 includes threecomponents/microservices that collectively provide login capabilities,including two platform microservices: OAuth2 1004 and SAML2 1006, andone infrastructure microservice: SSO 1008. In the embodiment of FIG. 10,IDCS provides an “Identity Metasystem” in which SSO services 1008 areprovided over different types of applications, such as browser-based webor native applications 1010 requiring 3-legged OAuth flow and acting asan OpenID Connect relaying party (“RP,” an application that outsourcesits user authentication function to an IDP), native applications 1011requiring 2-legged OAuth flow and acting as an OpenID Connect RP, andweb applications 1012 acting as a SAML SP.

Generally, an Identity Metasystem is an interoperable architecture fordigital identity, allowing for employing a collection of digitalidentities based on multiple underlying technologies, implementations,and providers. LDAP, SAML, and OAuth are examples of different securitystandards that provide identity capability and can be the basis forbuilding applications, and an Identity Metasystem may be configured toprovide a unified security system over such applications. The LDAPsecurity model specifies a specific mechanism for handling identity, andall passes through the system are to be strictly protected. SAML wasdeveloped to allow one set of applications securely exchange informationwith another set of applications that belong to a different organizationin a different security domain. Since there is no trust between the twoapplications, SAML was developed to allow for one application toauthenticate another application that does not belong to the sameorganization. OAuth provides OpenID Connect that is a lightweightprotocol for performing web based authentication.

In the embodiment of FIG. 10, when an OpenID application 1010 connectsto an OpenID server in IDCS, its “channels” request SSO service.Similarly, when a SAML application 1012 connects to a SAML server inIDCS, its “channels” also request SSO service. In IDCS, a respectivemicroservice (e.g., an OpenID microservice 1004 and a SAML microservice1006) will handle each of the applications, and these microservicesrequest SSO capability from SSO microservice 1008. This architecture canbe expanded to support any number of other security protocols by addinga microservice for each protocol and then using SSO microservice 1008for SSO capability. SSO microservice 1008 issues the sessions (i.e., anSSO cookie 1014 is provided) and is the only system in the architecturethat has the authority to issue a session. An IDCS session is realizedthrough the use of SSO cookie 1014 by browser 1002. Browser 1002 alsouses a local session cookie 1016 to manage its local session.

In one embodiment, for example, within a browser, a user may use a firstapplication based on SAML and get logged in, and later use a secondapplication built with a different protocol such as OAuth. The user isprovided with SSO on the second application within the same browser.Accordingly, the browser is the state or user agent and maintains thecookies.

In one embodiment, SSO microservice 1008 provides login ceremony 1018,ID/password recovery 1020, first time login flow 1022, an authenticationmanager 1024, an HTTP cookie manager 1026, and an event manager 1028.Login ceremony 1018 implements SSO functionality based on customersettings and/or application context, and may be configured according toa local form (i.e., basic Auth), an external SAML IDP, an external OIDCIDP, etc. ID/password recovery 1020 is used to recover a user's IDand/or password. First time login flow 1022 is implemented when a userlogs in for the first time (i.e., an SSO session does not yet exist).Authentication manager 1024 issues authentication tokens upon successfulauthentication. HTTP cookie manager 1026 saves the authentication tokenin an SSO cookie. Event manager 1028 publishes events related to SSOfunctionality.

In one embodiment, interactions between OAuth microservice 1004 and SSOmicroservice 1008 are based on browser redirects so that SSOmicroservice 1008 challenges the user using an HTML form, validatescredentials, and issues a session cookie.

In one embodiment, for example, OAuth microservice 1004 may receive anauthorization request from browser 1002 to authenticate a user of anapplication according to 3-legged OAuth flow. OAuth microservice 1004then acts as an OIDC provider 1030, redirects browser 1002 to SSOmicroservice 1008, and passes along application context. Depending onwhether the user has a valid SSO session or not, SSO microservice 1008either validates the existing session or performs a login ceremony. Uponsuccessful authentication or validation, SSO microservice 1008 returnsauthentication context to OAuth microservice 1004. OAuth microservice1004 then redirects browser 1002 to a callback URL with an authorization(“AZ”) code. Browser 1002 sends the AZ code to OAuth microservice 1004to request the required tokens 1032. Browser 1002 also includes itsclient credentials (obtained when registering in IDCS as an OAuth2client) in the HTTP authorization header. OAuth microservice 1004 inreturn provides the required tokens 1032 to browser 1002. In oneembodiment, tokens 1032 provided to browser 1002 include JW identity andaccess tokens signed by the IDCS OAuth2 server. Further details of thisfunctionality are disclosed below with reference to FIG. 11.

In one embodiment, for example, OAuth microservice 1004 may receive anauthorization request from a native application 1011 to authenticate auser according to a 2-legged OAuth flow. In this case, an authenticationmanager 1034 in OAuth microservice 1004 performs the correspondingauthentication (e.g., based on ID/password received from a client 1011)and a token manager 1036 issues a corresponding access token uponsuccessful authentication.

In one embodiment, for example, SAML microservice 1006 may receive anSSO POST request from a browser to authenticate a user of a webapplication 1012 that acts as a SAML SP. SAML microservice 1006 thenacts as a SAML IDP 1038, redirects browser 1002 to SSO microservice1008, and passes along application context. Depending on whether theuser has a valid SSO session or not, SSO microservice 1008 eithervalidates the existing session or performs a login ceremony. Uponsuccessful authentication or validation, SSO microservice 1008 returnsauthentication context to SAML microservice 1006. SAML microservice thenredirects to the SP with required tokens.

In one embodiment, for example, SAML microservice 1006 may act as a SAMLSP 1040 and go to a remote SAML IDP 1042 (e.g., an active directoryfederation service (“ADFS”)). One embodiment implements the standardSAML/AD flows. In one embodiment, interactions between SAML microservice1006 and SSO microservice 1008 are based on browser redirects so thatSSO microservice 1008 challenges the user using an HTML form, validatescredentials, and issues a session cookie.

In one embodiment, the interactions between a component within IDCS(e.g., 1004, 1006, 1008) and a component outside IDCS (e.g., 1002, 1011,1042) are performed through firewalls 1044.

SSO Service

In one embodiment, in the cloud environment of IDCS, when a tenant isprovisioned and requires protection for its application, IDCS providesidentity functionality such as authentication, authorization, audit,etc. When a user needs to use the application, IDCS provides thecomplete security of the identity of the user, and a particular type oftoken is generated and user access is established or secured for theapplication.

In one embodiment, the SSO service is used to protect different types ofclients/applications, where access to each particular application isprotected by a standard protocol, such as OAuth or SAML. The protocoldictates the token format, what tokens are required, and what browsersemantics are required to generate a particular token. Upon receivingthe token, an application may use the token-based claims to give accessto a particular user. In one embodiment, the token demands who the useris, who the actor is, what the scope is, and what is the audience thatis being accessed. In one embodiment, the token is different for OAuthand SAML, and includes the semantics of the user claim/statement whichthe user establishes after authentication.

Generally, standard-based protocols such as OAuth and SAML do notdictate or provide any specification that indicates how to generate atoken or how users should be authenticated. Instead, they only requireusers to be authenticated and dictate which token should be obtained.For example, for an OAuth or SAML token, the protocol only dictates thesemantics for the token, but does not dictate or specify how the usershould be authenticated, logged in, logged out, etc.

In one embodiment, however, the IDCS SSO service defines how aparticular user is authenticated (e.g., whether the authentication isone-factor, two-factor, biometric, etc.). In this embodiment, a sign-onpolicy or access policy indicates how a user is authenticated to accessan application. In one embodiment, after performing the authentication,IDCS converts the authentication into an IDCS session or “globalsession” (e.g., configured as a session cookie or a session token). Theglobal session is a cloud-aware session with specific semantics/format,and is configured for the IDCS multi-tenant environment. Depending on aparticular identity task to be performed for an application, IDCS canconvert the global session into an applicable token (e.g., an OAuthtoken, a SAML token, etc.) and provide the token to the application.

In one embodiment, the SSO service is a common controller system thatcan be used for any protocol (e.g., OAuth, SAML, social token, socialservice, etc., or any newly developed specification). In one embodiment,when a request is received by the SSO service, the request parametersare normalized. As such, the SSO service can remain common and servedifferent types of tokens. The SSO service does not need to knowspecific protocol semantics (e.g., OAuth-specific semantics orSAML-specific semantics).

In one embodiment, the SSO service defines a complete login ceremony asa common logic. The login ceremony dictates how a user is logged in,which factors are used for authentication, how the system performs thefactor authentication, how the orchestration happens between the userand the IDCS SSO service, etc. The SSO service also defines a logoutceremony that dictates how to log out of the global session and how toreplicate to different protocols. The SSO service provides protocoldriven application logout.

In one embodiment, the complete login ceremony happens between the SSOservice and UI interactions. The login ceremony depends on the factorsthat the user is using to log in (e.g., user ID and password,certificate based authentication, mobile factor based authentication,etc.).

One embodiment implements the SSO service as a common controller andalso implements an authentication module plug-in as a backendauthenticator for each login ceremony. For example, for authenticationbased on user ID and password, the embodiment implements a plug-in to goto the identity store that includes the user ID and password. Theplug-in then authenticates the user credentials to that store. Asanother example, if the user provides a certificate of user credentialssuch as an X.509 certificate, the SSO service determines the appropriateauthentication module, which in this case is a certificate module. Thecertificate module goes to a certificate store and validates theprovided certificate against the certificate store. In one embodiment,the user may provide a mobile authentication factor such as a shortmessage service (“SMS”) or a time-based one-time password (“TOTP”).

In some embodiments, the SSO service may determine to go to amultifactor authentication plug-in to authenticate a user. The SSOservice orchestrates the requirements for each plug-in. In variousembodiments, a plug-in may require one interaction with the user such asone user ID and password, or may require multiple interactions with theuser such as multiple pages.

Accordingly, the SSO service orchestrates the entire login ceremony fordifferent types of user authentication. Once the user is authenticated,the SSO service establishes the global session. In one embodiment, theglobal session is populated with various user information, such as userID, user preferences, user locale, user time zone, the factors ormodules it got authenticated to, the time of the authentication, etc.

In one embodiment, in the cloud architecture of IDCS, the services areconfigured as stateless and horizontally scalable, and no state ismaintained in the server. Accordingly, since the services cannotmaintain the session state of a client session, the entire session whichis the global session is put in a client cookie. That is, the embodimentconfigures the global session as a client cookie, and the client sessionis the cookie in which the entire global session is preserved. In oneembodiment, the cookie is part of the request header, and every time therequest goes back to the browser with “302”, and redirect comes back toanother service, the cookie is replayed (i.e., the header is replayed).

In one embodiment, the content of the global session is stored using aprotocol buffer to minimize its size so that the global session can beincluded in the cookie. One embodiment provides semantics for preservingthe global session, optimizing its size, and converting the cookie orclient session into a particular protocol-based token.

In one embodiment, a first flow is called when a user has already loggedinto a system (and thus has a global session in the system) and isaccessing another application with the same browser session. In thisflow, the protocol layers (e.g., 1004 and 1006 in FIG. 10) do notdetermine whether the user has a valid session because they do notunderstand the global session. Instead, they request the SSO service todetermine whether the user has a valid global session. The SSO servicethen goes into a mode where there are different flows it orchestrateswith a valid session depending on the protocol. It determines thevalidity of the session based on certain parameters, and if the user hasa valid global session, it generates the protocol specific token andgives access.

In one embodiment, a second flow is called when the validity of thesession is not sufficient and the user needs to be asserted and thereneeds to be a local identity.

In one embodiment, a third flow is called for first time logins. Whenthe user is authenticated (with a respective authentication module), andafter the orchestration is performed and the SSO service is about tocreate a session, the embodiment ensures that the user exists in thelocal IDCS user store. The user needs to have a local identity presence(e.g., maybe not a password if the user has authenticated remotely, butat least some minimum profile information). Similarly, in the flows whenthere is an existing valid session, the SSO service asserts the user inthe local store and ensures that the user exists in the local IDCSidentity store.

One embodiment provides a set of flows for a federation system.Federation provides cross-domain SSO and may include an SP, an IDP, orother actors and entities. For example, an SP and an IDP may be on adifferent domain (e.g., cookie domain, identity domain, etc.), and thesession may need to be transferred from one domain to another using afederation protocol such as SAML2. In one domain, the embodiment maycreate a local session or a global session that cannot be read byanother domain. Therefore, before going to the other domain (which alsohas to be a trusted domain), the embodiment converts the global sessioninto a SAML token, and transfers the SAML token into the other domainwhere it can be validated and asserted.

In one embodiment, there are different flows orchestrated by the SSOservice when behaving as a SAML SP or IDP. Generally, a user isauthenticated to a remote IDP when the user does not exist locally. Forexample, a user may have a cloud account to use a cloud service, but maybe an on-premise user or an existing enterprise user that does not wantto replicate its user identity into the cloud store. Since the useridentity is on-premise, on-premise becomes the remote IDP. In this case,the local IDCS SSO service behaves as an SP and contacts the remote IDP.

When the user comes to the SSO service that acts as a SP, the SSOservice uses a federation protocol such as SAML to go to the remote IDP.The authentication is performed at the remote IDP and a SAML token isgenerated on the remote IDP. The remote IDP sends the SAML token to theSSO service. The IDCS SAML service extracts the SAML token, extracts therequired attributes/statements from the SAML token (e.g., authenticationstatement, authorization statement, name, ID, etc.), normalizes thatinformation in a specific format, and then passes it on to the SSOservice. The IDCS SAML service does not perform assertion. The SSOservice does not need to orchestrate the user login ceremony since theremote authentication is already performed by the remote IDP on-premise.Instead, the SSO service gets a normalized SAML state in a normalizedattribute format, and asserts that state (asserts those attributes) inthe local system.

One embodiment provides different options/flags or configurations forfederation, for example, whether the user must exist locally even if itis authenticated remotely, whether to ignore the existence of the userin the local system, etc. Based on that, the SSO service either assertsthe user locally or just asserts the claim, and then creates the globalsession. The SSO service then gives the request back to the protocoltier (i.e., the SAML service).

In one embodiment, the global session in the entire IDCS system is thesource of truth for any protocol tokens to be generated. The globalsession is generated by the SSO service based on different types offlows that it orchestrates, such as new authentication, existingsession, remote authentication for federation, remote authentication forOAuth or social login, etc. The IDCS system can then generate a tokenfor different protocols and give the token back to the application, andbased on the token, a client can access a tenant application.

Normalized State

One embodiment supports the global session by providing normalizedparameters for different protocols such as SAML and OAuth, while eachone of the OAuth and SAML services receive their respective tokens. Forexample, the SAML service receives the SAML assertion which is an XMLblock with a header and a body. The header defines the type of the tokenor the type of the security mechanism used to generate theauthentication, which may be, for example, X.509, user ID/password, etc.In one embodiment, the SAML token is according to SAML2 specifications.The SAML service extracts the SAML token, reads it, and validates eachpart of it. The body of the token may include the SAML assertion such asname ID, authentication statement (indicating the type of authenticationused by the remote IDP), etc.

The token also includes an authorization statement (indicating theattributes used for authorization) and an attribute statement(indicating the remote IDP) after the authentication has transferredsome attributes. In one embodiment, the remote IDP has a real identitystore for the user and uses that to authenticate the user, and sendsback some attributes in the SAML token based on the attribute statementrequirements. The attributes that need to be sent are determined basedon the SAML configuration established between the IDP and the SP. In oneembodiment, before an entity becomes an IDP for an SP or an SP for anIDP, both entities have to be trusted entities, and there is a metadataexchange performed as a prerequisite. They also share their certificates(e.g., the public keys/certificates) to establish the trust and theconfiguration that each one needs from another. When an SP gets a SAMLassertion, the attribute statement is based on the configurationstatement that the SP has dictated to the IDP (e.g., what attributes tobe sent to the SP after a SAML token is generated).

In one embodiment, the SAML service knows only the SAML semantics. Itcan open the SAML token, verify the signature, and if it is encrypted,decrypt it based on signing and encryption algorithms. The algorithmsare also part of the configuration between the SP and the IDP. In oneembodiment, all this is performed at the protocol layer where the SAMLservice gets the attributes out of the token. In one embodiment, theSAML service normalizes the attributes as key/value pairs (e.g., anattribute name and a value). In this embodiment, the key/value pairconfiguration is a generic format that is not based on any specificprotocol. The normalized state of attributes is received as key/valuepairs by the SSO service. In one embodiment, the same normalization isperformed on the OAuth tokens at protocol level claims. That is, OAuthclaims are also normalized in the same key/value pair format.

In one embodiment, a protocol can give attributes as part of theauthentication protocol, demand attributes, and/or after a globalsession is established, dictate where the SSO service should go back toafter authentication/verification is performed (e.g., aprotocol-service-based go-back URL on which to call back). For example,for SAML, the attributes are received by the SSO service, while forOAuth, the SSO service provides the attributes since it authenticatedthe user. In one embodiment, for example, the SAML protocol may receivethe attributes from a remote entity (e.g., a remote IDP) or indicatethat it needs the attributes back. In case of OAuth, the protocoldictates that after a global session is established, the protocol needssome attributes back to generate OAuth-based claims for an endapplication. In one embodiment, OAuth or SAML may require the SSOservice to go to certain endpoints/URLs. This information comes back tothe SSO service as state information from both protocols.

In one embodiment, the communication to/from the protocol layers (e.g.,SAML and OAuth services) and the SSO service is by “redirect” (throughHTTP 303) and they share the common state in an encrypted cookie. Theencrypted cookie stores the protocol information and the normalizedformat which is configured to be concise and suitable for differentbrowser limitations (e.g., header size, cookie size, etc.).

Request State

In the cloud architecture of the embodiments, the services arestateless. Accordingly, one embodiment provides a common state thatflows through for different layers to interact with each other. Theembodiment preserves the state at the client (in the form of encryptedhost cookies) over the duration of various flows, for example, when theprotocol layer contacts (HTTP redirects to) the SSO service forauthentication when there is no SSO session, when the protocol layercontacts the SSO service for session validation and user assertion withan existing session, etc.

In one embodiment, the common state includes client sessions and clientstates. The embodiment provides a “request state” and includes it in a“request cookie” as header. The request cookie is not an SSO cookie oran authenticated session, but a pre-authenticated state that ismaintained across different services (e.g., protocol services, SSOservice, etc.). It also includes execution context (e.g., states such asauditing, diagnostics, etc.). The normalized state (e.g., theattributes, the go-back URL, what is required for different flows, etc.)is also captured in the request state and placed in the request cookie.In one embodiment, this cookie is encrypted and the encryption key issecurely stored and periodically rolled over (e.g., every 12 hours) sothat it cannot be hijacked.

In one embodiment, the state information stored in the request statedoes not include user security data such as passwords. In oneembodiment, even during interaction between protocols, only the claimsare stored in the request state and the signatures are attached to theclaims.

In one embodiment, the request state that is used during the loginprocess (e.g., login ceremonies or different flows) may also be usedduring the logout process since this state includes information on thedifferent endpoints that the user has visited and needs to go back to orlogout for the protocol, the normalized state for each protocol, theclaims, the attributes needed to assert the user in the identity system,etc.

In one embodiment, in order to preserve the state at the client (in theform of encrypted host cookies) over the duration of various flows, thebelow representations are implemented:

-   -   “UserRequestData” which is created every time the protocol layer        initiates a fresh request to the SSO service for        creation/validation of an existing session;    -   “UserSessionData” which is created by the SSO service on        completion of handling the request form the protocol layer (once        this is created, “UserRequestData” is deleted and all the        relevant data is persisted in it);    -   “AbstractUserData” which is the parent of “UserRequestData” and        “UserSessionData” and includes the common state data structures        used by both.

Table 1 provides the functionalities included in “UserRequestData”representation in one embodiment.

TABLE 1 Example functionalities included in “UserRequestData”representation String ssoRequestRemotePartnerID OAuth client ID or SAMLSP ID set by the OAuth/SAML-IDP server to identify the protocolinitiating the request String ssoRequestRemotePartnerName Name of theremote partner corresponding to the partner ID used for global auditString ssoRequestProtectedRequestedURL The URL accessed by enduser/client that triggered the authentication request from protocollayers String ssoRequestReferrer Set by the protocol layer to thereferrer that initiated the request. It is also used to identify specialcases such as the “break-glass flow” (e.g., in order to avoid an endlessloop when a single remote IDP is used and is down, through the use of anadministration console) String ssoRequestCallbackURL Set by the protocollayer to the URL the SSO server has to revert to after handling therequest. It can also be set by SAML-SP server in IDP-initiated SSO flowsand point to return URL/relay state sent by IDP String logoutDoneURL TheURL where the SSO service will redirect the user after logout iscompleted, can be null

In one embodiment, “UserSessionData” representation includes “byte[ ]authnContext” which is the concise binary representation of user sessiondata, e.g., the attributes defined by an “AuthContext” object. Theprotocol buffers library is used to effectively represent the data inbinary format. It is encrypted using a private key rolled over, e.g.,every 12 hours. Table 2 provides the functionalities included in the“AuthContext” representation in one embodiment.

TABLE 2 Example functionalities included in “AuthContext” representationString userId Logged in user globally unique ID (“GUID”) StringuserEmailId User's email ID principal String sessionId Current sessionID String userDisplayName User's display name String tenantName User'stenancy Map<String, String> claims Authentication claims of the user(e.g., user attributes from the IDCS (local) IDP or remote IDP) longsessionExpirationTime Session expiry time long sessionCreationTimeSession creation time String userLoginId User login attribute value incase of local authentication String userMappingAttr User login attributename in case of local authentication

Table 3 provides example functionalities included in “AbstractUserData”representation in one embodiment.

TABLE 3 Example functionalities included in “AbstractUserData”representation Map<Integer, byte[ ]> componentData Holds the AbstractSyntax Notation One (“ASN.1”) or protocol buffer encoded serializedbinary representation of each component's data either scoped to requestor session Date generationTime Request or session cookie setting time atserver String tenantName User tenancy for the session

In one embodiment, the components corresponding to “Map<Integer, byte[]> componentData” may be, for example, SSO, OAuth2, and SAML servers.The data is binary so that it can be encrypted and the private keymanagement can be abstracted out of the component data representation.As part of the “UserSessionData”, it holds the tracking data of eachclient or partner to whom a token/assertion was issued in the durationof the session. This helps in global logout too. As part of the“UserRequestData”, it holds the component level request scoped data.

In one embodiment, the SSO Service implements a resource manager and aSSO Runtime. Resource manager is the common data access layer for IDCS.It is metadata driven so it can manage any resource type defined in aSCIM compliant resource type and schema definition. Resource managerhandles all common logic for all resource types including schema-basedvalidation of attributes, data types, required values, canonical values,etc. It also handles setting default values, setting “create/updatedate” values, setting “create/update by” values, protecting sensitiveattributes, mapping to target attributes, authorization checks, andevent publishing. A resource-type data manager's external interface isHTTP/REST (deployed in the IDCS Admin server and brought up by a“serviceUp” command), and its internal realization is through Javainterfaces. In one embodiment, the implementations are injected based onJava Specific Request (“JSR”) 330, using Hundred-Kilobyte Kernel(“HK2”). The resource type payload follows the resource model asoutlined by SCIM 2.0. For example, “/Applications” and “/Credentials”are specific resource types.

The resource definitions and schema are discoverable through“/ResourceTypes” and “/Schemas.” Resource-type data managers manageoperational data per tenant (e.g., Users, Groups, Tokens, ResourceTypes, Schemas, etc.), tenant settings (cross-service tenant-specificsettings and service-specific tenant-specific settings), and globalconfiguration (cross-service global configuration and service-specificglobal configuration).

SSO Runtime

FIG. 10A illustrates an example block diagram 1000A of SSO runtime inone embodiment where SSO service 1002A implements the user login/logoutceremonies for local and federated logins. The Cloud SSO integrationarchitecture uses the standard OpenID Connect user authentication flowfor browser-based user logins. Since Cloud login is based on OpenIDConnect, OpenID Provider (“OP,” illustrated as OAuth OP 1004A in FIG.1000A) is where the login request reaches SSO 1002A. Internally, theruntime authentication model is stateless, maintaining the user's SSOstate in the form of a host HTTP cookie.

The user login request flow is as follows: the user accesses abrowser-based application or a mobile/native application; connectingapplication (OAuth RP 1006A or application's Enforcement Point) detectsthe user has no local application session and requires the user to beauthenticated; connecting application (OAuth RP 1006A or application'sEnforcement Point) initiates OpenID Connect Login flow against OAuth2Service (3-legged AZ Grant flow with scopes=“openid profile”); andOAuth2 Service (OAuth OP 1004A) constructs the application context andredirects to SSO Service 1002A.

In one embodiment, the service level agreements (“SLAs”) between OAuthOP 1004A and SSO 1002A include the following:

-   -   IDCS_REQUEST—IDCS_REQUEST HTTP cookie is used to maintain the        state between various request/response flows between SSO 1002A        and Channel components.        -   CallbackURL: This is set by OAuth OP 1004A before            redirecting to SSO 1002A. SSO 1002A redirects to this URL            after processing.        -   ErrorCode: This is how SSO 1002A communicates back to OAuth            OP 1004A about any error that occurred.        -   ErrorMessage: Localized SSO error message.    -   IDCS_SESSION        -   If authentication status is “success” then SSO 1002A creates            IDCS_SESSION with authentication and redirects the user            to/callBackUrl in IDCS_REQUEST.        -   In case a valid IDCS_SESSION is already present, SSO 1002A            asserts the user fetched from the IDCS_SESSION cookie.

One embodiment may also implement a persistent cookie that can storeuser preferences such as user locale. This cookie may be used totranslate the error message to user-specific locale.

In one embodiment, as per the IDCS microservices architecture, a UIservice 1008A (Login App/Logout) is implemented as a separate service,and not as part of SSO 1002A. UI service 1008A and SSO service 1002Ainteract with each other via a REST endpoint implemented in a REST layer1010A in FIG. 1000A, and state information is passed as JSON payloadbetween SSO service 1002A and REST layer 1010A.

In one embodiment, SSO service 1002A includes REST layer 1010A, a SSOController 1012A, a Credential Collector 1014A, an AuthenticationManager 1016A (for plugging in different modules and call, authenticate,and validate on each one), a Session Manager 1018A, an SSO Event Manager1020A, an SSO Client APIs Integrator 1022A, Error Handling 1024A, and anassertor (asserting based on different identity, not shown in FIG.1000A). In one embodiment, when an authentication request reaches theGET method of SSO 1002A at “/sso”, the request includes request andstate data submitted to SSO 1002A by OAuth OP 1004A (corresponding toOAuth RP 1006A) or a SAML IDP 1005A (corresponding to a SAML SP 1007A)as an IDCS_REQUEST HTTP cookie. The IDCS_REQUEST cookie is decrypted andparsed, and parameters and other HTTP headers are captured in a RequestContext object and passed to SSO Controller 1012A. SSO 1002A collectsthe user's credentials by redirecting to the login page (implemented byUI Service 1008A), and the login page submits the credentials to thePOST method of SSO 1002A. The state information is passed as JSONPayload between them.

In one embodiment, SSO Controller 1012A is a class that determines whataction to take depending on the state of the request. There may bevarious states indicative of Credential Collection, CredentialValidation, First Time User, Forgotten Password, Password Reset, etc.SSO Controller 1012A orchestrates the flow to the other componentsdepending on the various conditions.

One embodiment supports two forms of authentication: Basic and Form. Therequired credentials such as username, password, and tenant name arecollected at Credential Collector 1014A and passed for authentication.This class prepares the JSON request to be sent to the Login UI andparses the response received from the Login app.

Authentication Manager 1016A is a class that validates IDCS UserID/password and/or issues Authentication Tokens. There may be variousresults of Authentication, such as Authentication Success, InvalidCredentials, Disabled User, Password Has Expired, Password Needs To BeReset, etc. The proper Error code is returned as part of the SSOResponse. Authentication Manager 1016A talks to “/UserAuthenticator”REST endpoint of a User/Identity Manager 1030A (Resource Manager inAdmin service) to execute the actual validation of the credentials. Inone embodiment, Authentication Context 1017A (the global session) andAuthentication Claims of the user are created at Authentication Manager1016A. If Authentication Context 1017A is already present in therequest, it is asserted by talking to the same User AuthenticationService to assert the token instead of validating the credentials.

In one embodiment, Session Manager 1018A communicates with a CookieManager 1028A and manages the SSO cookie, including storage ofAuthentication Context and metadata on connecting applications. CookieManager 1028A is a common layer shared with all the other layers andgenerates and optimizes the global session state making it as a clientsession cookie. Upon successful authentication or validation, SSOService 1002A redirects back to the OAuth Service with the newlycreated/updated SSO host HTTP cookie that includes the User'sAuthentication Token. SSO service 1002A removes request-specific datafrom the cookie. The following is an example functionality for readingcookie data from the HTTP Servlet Request:

CookieManager cm=CookieManagerFactory.createlnstance(request, response);

UserSessionData sessionData=cm.getSessionData( );

String myAuthnToken=sessionData.getAuthnToken( )

byte[ ]mySamIData=sessionData.getComponentData(CookieManagerComponents.SAML);

sessionData.setAuthnToken(“4141FB74579EAB131ECF6369 . . . ”);

cm.setSessionData(sessionData);

cm.commit( );

In one embodiment, an example of cookie data in the HTTP request is asfollows:

Two cookies:

Entry #1:

Name: “ORA_OCIS_1”

Value: “624790624790578067acbe05a58a589c5595346236e57a5c373b83e3758ac38”

Entry #2:

Name: “ORA_OCIS_2”

Value:“6246bef44242bf6246bef44242bf6246bef44242bf6246bef44242bf˜4˜6246bef44242bf”

In one embodiment, SSO Event Manager 1020A communicates with an EventManager 1032A and publishes events associated with the SSO flow. Oneembodiment defines SSO events and what their targets are (e.g., Audit,Analytics, Notification, Metrics, etc.). The following are correspondingexample functionalities:

ssoservice.authentication.success

ssoservice.authentication.failure

ssoservice.server.startup

. . .

import oracle.idaas.common.event.*;

Event event=new EventImpl.Builder(SystemEventId.SYSTEM_ERROR_RUNTIME)

-   -   .ecid(“123-456-7890”).rid(“relationship id”)    -   .eventValue(“event value”).serviceName(“service name”)    -   .actorld(“actor id”).actorName(“actor name”)    -   .tenantName(“test tenant”).message(“test message”)    -   .eventData(“name3”, “value3”).build( );

eventManager.publish(event);

In one embodiment, SSO Client API Integrator 1022A communicates withResource Manager 1026A, and tenant specific SSO Settings are stored andavailable in the Admin Server's Resource Manager 1026A. The SSO settingssuch as AuthN scheme, session timeout, etc., are read in SSO runtimeserver via REST requests. Since reading these settings involves anetwork call, they can be cached per tenant, provided there is acallback mechanism to get notified for any change in these settings. Thefollowing is an example of the functionality of Resource Manager 1026A:

String url=“http://” +hostName+“:” +port;

IdaasClient client=IdaasClient.login(tenantName, username, password);

client.setTargetURI(URI.create(urI));

SSOSettingsService service=client.getService(SSOSettingsService.class);

SSOSettings ssoSettings=service.get(“SSOSettings”, null);

ssoSettings.getCookieSessionTimeout( )

ssoSettings.getMaxLoginAttempts( )

In one embodiment, UI Service 1008A provides the interaction point forend users consuming SSO service 1002A, and provides operations such as:

-   -   Credential collection from end users for authentication,        password management, and invoking the respective SSO Service        endpoint via a JSON-based rest call;    -   Handling various error scenarios for the JSON rest calls        initiated with SSO service 1002A;    -   Handling various errors raised by SSO service 1002A and        encountered during the interaction with protocol layers through        a Redirect initiated by SSO Service 1002A.

In one embodiment, SSO Controller 1012A serves UI Service 1008A for theabove cases according to the following flows.

In the protocol 3-legged end user flow:

-   -   End user accesses application protected by RP 1006A (e.g.,        protocol-specific gate keeper agent);    -   RP 1006A triggers protocol interaction and protocol layer        redirects to the endpoint “/sso/v1/user/login”;    -   The endpoint returns on SSO service 1002A after setting the        context in the IDAAS_REQ cookie;    -   SSO service 1002A reads the tenant header in the IDAAS_REQ        cookie, and based on tenant configuration, calls either remote        IDP 1036A or login UI service 1008A by redirecting to the        endpoint “/member/v1/signin”;    -   UI service 1008A collects credentials and submits them via a        JSON request to the post method on the endpoint        “sso/v1/user/login”;    -   SSO service 1002A validates the credentials. On failure,        responds with hierarchical (e.g., 2 level: major and minor)        error codes to UI Service 1008A. On password reset, the next        operation (“nextOp”) and respective error codes are sent to UI        Service 1008A. On success, if post login is enabled, respective        nextOp is sent to UI service 1008A. On Success, if post login is        disabled, the JSON response is returned with the nextOp as        “redirect” with the “redirectUrl” in the payload. The        “redirectUrl” is the call back URL of the protocol layer        obtained from the IDAAS_REQ cookie. In either of the success        cases, the IDCS_SSO cookie is created and is set in the user's        browser on response;    -   If post login is enabled and the operation is completed by UI,        in case of dissent or consent, the control comes back to SSO        Service 1002A through a JSON request;    -   SSO Service 1002A updates the IDAAS_REQ cookie with        Consent/Dissent and sends the response with the nextOp as        “redirect” with the “redirectUrl” in the payload;    -   The protocol layer reads the IDCS_SSO Cookie and generates the        protocol specific token to return to RP 1006A;    -   RP 1006A sets the application-specific cookie reading the token        and the user is then granted access and can access the        application with the cookie.

In the Basic Auth flow from Cloud Gate:

-   -   The end user/client accesses the resource protected by Cloud        Gate with the username and password authorization header.    -   Cloud Gate verifies the resource is protected by Basic Auth and        calls the SSO endpoint at “/sso/v1/user/login” with a post HTTP        request and credential data in the payload.    -   The absence of IDCS_REQUEST and presence of attributes: “RPID”,        “Referrer” are the conditions to branch the SSO Controller flow        to a different handler: “BasicAuthHandler.java” to handle Basic        Auth.    -   The “BasicAuthHandler” performs just validation of the        credentials in the JSON payload and responds with the        success/failure information without setting the IDCS_SSO cookie        with the authentication context.    -   It also handles the SSO events for authentication and propagates        the error codes during credential validation with the JSON        response.

In the Auto login (on first time use) and password change flow from UI:

-   -   The Tenant administrator provisions the user and their Email        from the admin UI and an Email including a URL with limited        period token is sent to the user.    -   The user clicks the link to access UI service 1008A with the        token. UI service 1008A validates the token with the identity        service and collects the credentials.    -   UI service 1008A posts the credentials to the identity service        to update to the backend.    -   UI service 1008A further posts to the SSO Controller endpoint        “/sso/v1/user/login” for auto login with “redirectURL” attribute        set in JSON payload with operation/op: “cred_submit and no        IDCS_REQ cookie. This is handled by the “CredSubmitHandler”.    -   SSO Controller 1012A gets the redirect URL in the following        order of priority:        -   1) callback URL from the IDCS_REQUEST;        -   2) “redirectURL” attribute in the JSON payload only if            IDCS_REQUEST cookie is not present;        -   3) If neither “IDCS_REQUEST” cookie or “redirectURL”            attribute are present, uses the “my services” URL for            redirection on successful authentication.

SSO State and Flow

FIG. 10B illustrates an example state and flow diagram 1000B of SSOfunctionality in one embodiment. The embodiment of FIG. 10B provides anexample of the SSO controller engine flow diagram for each identityoperation such as forgotten password, account log, a request coming fromSAML SPs and IDPs, etc. In this embodiment, SSO service 1002 a has amodular configuration in which the modules use the global state tointeract with each other as well as with the protocol layer (e.g.,OpenID connect, SAML, etc.). The embodiment provides a novel mechanismto communicate the state in a secure manner. The size of the state isconfigured efficiently so that the state occupies a small space and theoperations are performed faster. The embodiment is configured in anadaptive way to ensure that it can be enhanced to multifactorauthentication, step up authentication, etc. The embodiment provides anadaptive configuration so that additional authentication plug-ins can bereadily added and additional step up authentication can be provided. Theembodiment can also use the same components/modules to perform otherfunctionality such as policy based authorization check, etc.

In one embodiment, the interactions between the protocol layers (e.g.,OAuth, SAML, etc.) and SSO service 1002 a are performed through HTTP.They communicate through a certain state difference in the requestcontext (parsed in the cookie) and they always know where to go back to(based on a fixed attribute in that state). For example, when SSOservice 1002 a gets control and determines where to go based on theprotocol it got the request from, the protocol has set an end URL or areturn URL into the state, and SSO service 1002 a follows that based onwhat SSO service 1002 a finds out after authentication or after successor failure. Similarly, when a protocol gets some information withrespect to, for example, a request for a token, it tracks in adesignated component in the request cookie.

In one embodiment, the state includes different map objects includingcomponent data for each protocol. For example, when OAuth gets anauthorized request, it includes tracking information indicating fromwhom it got the request, etc. In one embodiment, OAuth tracks theinformation in a specific component data and initializes the requestcookie. The key for writing in the request cookie is shared between thecomponents (e.g., OAuth, SAML, SSO, etc.), and there is a commonunderstanding between these components as to, for example, what andwhere the data should be written, when the data should be written, etc.For example, when the embodiment has to document “n” number of roundtrips, there is a common understanding on what amount of data should beput in the request cookie and how, so the cookie is available as much aspossible to the next component. The state flows through as the encryptedand secure cookie. When there is a security concern in terms of flowingdata as an encrypted cookie, one embodiment configures the state as anencrypted payload post instead of a request cookie going in on a “302”.The embodiment ports as a HTTP post.

In one embodiment, for example, an RP 1016 a may receive a request froma browser for accessing protected resources. RP 1016 a sends a302/authorize or 302 SSO/SLO to an IDCS OP/IDP/SAML SP 1020 a, which inturn sends a 302 /sso/v1/user login with IDCS_REQUEST applicationcontext to SSO Controller 1004 a.

IDCS login flow is a sequence of request/response flows between SSO, OP,SAML IDP, SAML SP and Login App (Credential collection and PasswordManagement JS client) to provide Web single sign-on. The IDCS_REQUESThttp cookie is used to maintain the state between variousrequest/response flows between SSO and Channel components. The key forthe IDCS_REQUEST cookie will be shared between SSO and Channelcomponents. Login App and SSO service will interact with each other viaREST endpoint. The state information will be passed as JSON Payloadbetween them.

Request Behavior

IDCS SSO service 1002 a processes following different types of requests:(1) Request from IDCS OP/IDP service 1020 a; (2) Request from IDCS SPservice 1020 a; (3) Ajax HTTP POST Request from Login app submittingAuthentication credential from Login App 1042 b; (4) Ajax HTTP POSTRequest from Login App 1042 b after successful completion of Passwordmanagement operation; and (5) Ajax HTTP POST Request from Login App 1042b after successful completion of Post Login operation.

The request from OP/IDP service 1020 a will have Request+State datasubmitted by OP/IDP to SSO as an IDCS_REQUEST http cookie. The cookiewill be saved as IDCS host cookie, with encrypted data, etc. The key forthe cookie will be shared between OP/IDP/SSO. The key will be awell-named Key Resource created at the time of initializing tenant dataduring Tenant Create operation as follows:

-   -   1. RP ID—id of the connected app represented by the RP/SP;    -   2. Referrer—HTTP referrer at the time of User Browser being        redirected to OP/IDP;    -   3. Callback URL—URL pointing back to OP/IDP login response flow.

For the response behavior for request from OP/IDP:

-   -   1. SSO will update the IDCS_REQUEST cookie with Login app state        and redirect to Login app to show dynamic login with all        configured login options;    -   2. If federation SSO is the only option, then SSO itself will        redirect to IDCS SP service to initiate federated SSO with        remote IDP;    -   3. In case of valid IDCS_SESSION, SSO will assert the user        fetched from the IDCS_SESSION cookie.

a. On failure to assert the user SSO will update IDCS_REQUEST cookiewith assert failure detail, remove the IDCS_SESSION cookie and redirectto Login App. Login App will show login page with customized error basedon the Login app state.

b. On successful assertion, SSO will update IDCS_SESSION with channellogout detail if it is not there, Sets the content of the IDCS RequestCookie as the IDCS_REQ query/POST parameter, Removes IDCS request cookieand redirect to IDCS channel/callbackUrl stored in the IDCS_REQUESTcookie.

For the request from SP service, the SP service:

-   -   1. Reads and removes the SAML-SP state from the IDCS Request        Cookie;    -   2. Processes the SAML Assertion and maps it to local user;    -   3. Sets the results of the Federation SSO operation (status,        userID . . . ) as the OCIS_REQ_SP query/POST parameter;    -   4. Redirects to SSO Service with the IDCS_REQ query/POST        parameter.

For the response behavior for the request from SP, in case of validIDCS_REQUEST with SP state, SSO will check the SP state:

-   -   1. If SP state status is failure, then SSO will update        IDCS_REQUEST cookie with assert failure detail and redirect to        Login App. Login App will show login page with customized error        based on the Login app state.    -   2. IF SP state status is success then SSO will create        IDCS_SESSION with authentication context check the whether it is        IDP Initiated federation and post login is not enabled then:        -   a. idcsSSOInitiated: contains whether or not the flow was            started by the SSO service (boolean)        -   b. If false, then the SSO service will need to check            ssoResponseFedSSOReturnURL            -   i. If ssoResponseFedSSOReturnURL is null, then SSO                service will remove the IDCS Request Cookie and redirect                to MyConsole            -   ii. Otherwise, SSO service will remove the IDCS Request                Cookie and redirect to ssoResponseFedSSOReturnURL        -   c. If true, the SSO service will redirect to the            callbackURL, since the Federation SSO flow was started by            IDCS SSO service.    -   3. If post login is enabled, then SSO will redirect the user to        Login App with login App state updated with the flag to indicate        it is post login flow.

For the request from login app submitting authentication credential, thelogin app collects the credentials and posts the credentials to the SSOservice REST endpoint. The credentials are sent as JSON payload.

For the response behavior for the request from login app submittingauthentication credential, SSO will authenticate the postedauthentication credentials and check:

-   -   1. If authentication status is success, then SSO will create        IDCS_SESSION with authentication and redirect the user        to/callBackUrl in IDCS_REQUEST or sends Ajax Response to Login        App based on the tenant specific configuration.    -   2. If authentication status is Failure and reason is ‘Password        Expired’ then SSO send Ajax Response with JSON payload having        Password management state to let Login App start the password        reset operation. State contains User identity information and a        flag to indicate the indented operation is ‘Password reset for        expired password’.    -   3. For all other authentication status failure reasons, SSO will        send Ajax Response with JSON payload having Login App state.        Login App state will be used by Login App to show custom error        message.

For the request from login app after successful completion of passwordmanagement operation, the login app collects the new password andvalidates the same with configured tenant specific policy rules. Onsuccessful completion of password reset Login App checks theavailability of IDCS_REQUEST cookie. If IDCS_REQUEST cookie isavailable, then it sends Ajax POST request to SSO service REST endpointwith JSON payload having Password management state. If IDCS_REQUESTcookie doesn't exist Login App will redirect to IDCS Admin console URL.

For response behavior for request from login app after successfulcompletion of password management operation, SSO will assert the userinfo in Password Management state:

-   -   1. If assertion resulted in a failure, then SSO will send Ajax        Response to Login App state with failure detail as JSON payload.    -   2. If assertion resulted in success, then SSO will create        IDCS_SESSION and redirect the user to /callBackUrl in the        IDCS_REQUEST if Post login is not required or send Ajax Response        with Login App state as JSON payload to Login App to show the        post login page.

For the request from login app after successful completion of post loginoperation, the login app shows the post login pages and process the postlogin related operations. On successful completion of post loginoperation Login App sends Ajax POST request with Login App state withflag to indicate successful post login operation as JSON payload. IfIDCS_REQUEST cookie doesn't then Login App will redirect to IDCS Adminconsole URL.

For the response behavior for request from login app after successfulcompletion of Post Login operation, SSO will check Post Login flag isset by Login App in the Login App state. If it is set, then:

-   -   1. idcsSSOInitiated: contains whether or not the flow was        started by the SSO service (boolean)        -   A. If false, then the SSO service will need to check            ssoResponseFedSSOReturnURL            -   i. If ssoResponseFedSSOReturnURL is null, then SSO                service will remove the IDCS Request Cookie and redirect                to MyConsole            -   ii. Otherwise, SSO service will remove the IDCS Request                Cookie and redirect to ssoResponseFedSSOReturnURL        -   B. If true, the SSO service will redirect to the            callbackURL, since the Federation SSO flow was started by            IDCS SSO service.

As disclosed, embodiments provide an SSO service that dictates how auser is authenticated and how the login ceremony is performed. The loginmay be based on different types of authentication factor configurations(e.g., one factor, two factor, biometric, etc.). The embodiment ismodularized (not a monolithic piece of code) and includes a controllerlayer, and each specific authentication is implemented as a plug-in(e.g., a plug-in module for user ID password which can authenticate toLDAP, a plug-in module for X.509 authentication to authenticate to acertificate store, a plug-in for mobile authentication based on a mobilefactor for SMS, a plug-in for registration based on a QR code, etc.). Inone embodiment, the SSO system includes a service provider interface(“SPI”) layer where authentication modules can be plugged in. Theembodiment orchestrates the flows where the UI submits credentials to bevalidated. The embodiment performs SSO functionality irrespective of theprotocol layer, whether it is OpenID connect, SAML, OAuth, etc. Theembodiment provides the SSO service as a central controller for theentire IDCS access for login and logout flows, and uses a rich,optimized, and normalized state to make the service agnostic to allprotocols. One embodiment provides functionality to assert a user to adifferent identity stores (e.g., a remote IDP, a local identity store,etc.).

Single Logout (“SLO”)

One embodiment provides a global logout procedure that is agnostic tothe protocols used for protecting each of the applications. In oneembodiment, the logout procedure can trigger the logout of each protocolendpoint and also trigger the logout of the actual application that eachprotocol is protecting.

In one embodiment, for example, when there are several applicationsprotected by OAuth, the OAuth service reaches the SSO service to obtainthe entire global session and global state. The global state ismaintained as a map and includes the normalized state from eachprotocol. For each protocol, the global state saves the endpoint to goback to and the visited URLs that the protocol has protected. The SSOlogout can trigger not only the protocol logout but also the logout ofeach application, the logout images, or the logout endpoints.

In one embodiment, after each logout, the control comes back to the SSOservice (i.e., the request flow comes back to the SSO service) so thatthe embodiment can provide a novel central logout controller. Forexample, the logout may start from an application endpoint and then goto the corresponding protocol. The protocol then comes to the SSOservice, and the SSO service triggers the logout of the protocol as wellas all the visited applications protected by the protocol. Once that isdone, the control again comes back to the SSO service.

The SSO service then determines if there is anything else in the globalstate that the SSO service needs to trigger a logout for so that aglobal logout is accomplished. For example, if logout for OAuth is done,the SSO service determines if there is another protocol for which logoutis not yet done. The next protocol may be, for example, SAML. All ofthis information is in the normalized global state.

If the next protocol that needs logout is SAML, the SSO service triggersSAML logout in a similar fashion (e.g., the protocol logout, logout ofactual visited state protocols or applications, etc.). When SAML logoutis done, the control comes back to the SSO service again, and the SSOservice determines the next protocol logout to trigger. Accordingly, theSSO service keeps triggering logout for all the protocols and all thevisited applications (as identified in the global state) to complete theglobal logout.

One embodiment securely stores normalized logout endpoint information inthe global state. One embodiment does not store all the logout redirectURLs, but instead stores a pointer to each client that has access.Generally, OAuth and SAML both include provisions for storing the logoutredirect URLs for individual applications. When an OAuth applicationaccesses the OAuth service, a corresponding client ID is tracked and ispersisted in a respective specific component in the SSO session.Similarly, when a SAML application accesses the SAML service, acorresponding SP ID is tracked and is persisted in a respective specificcomponent in the SSO session. When the global logout URL is triggered(e.g., by accessing one of the application logout URLs, the SSO globallogout URL, etc.), the control always comes to the SSO service. The SSOservice then removes the global session, updates the session cookie withexpiry set to the current time so that it is no longer used, and causeseach component to logout.

One embodiment ensures that the control comes back to the SSO serviceafter each logout. In order to do so, when triggering the logout, theembodiment determines the list of applications that have been accessedor tracked as part of the session, constructs the logout URLs as imagesources embedded in an HTML page, and configures the last image sourceas the redirect URL of SSO. Once this dummy HTML page is sent as aresponse to the user browser, and the HTML page is loaded, the imagesources are loaded asynchronously. Because each image source is a logoutURL, a logout is triggered, and the response includes the set cookiecalls that unset the cookie of each individual application. Since onepart of the last image is the redirect URL of SSO, the embodimentasynchronously calls the SSO service, and the request flow comes back tothe SSO service.

In one embodiment, once the SSO service sends this HTML page with thelist of the components for which logout is already triggered, it removesthose components. Therefore, the next time the control comes back to theSSO service, it knows what logout has been done and what is yet to belogged out, and it proceeds until the list is empty.

As such, one embodiment triggers a global logout by organizing differentlogout endpoints of different applications into images, embedding theminto an HTML page, having the protocols to redirect to that page so thatall the images are loaded and the logout URLs are followed, and alsoembedding an image to come back to the SSO service. The different logoutendpoints of different applications may be based on different protocols,e.g., SAML, OAuth, etc.

In one embodiment, for example, when an end user has severalapplications which are protected by OAuth, the SSO service establishes aglobal session. While accessing those applications, the user may alsohave several other applications that are protected by a SAML token basedon the same global session. Once the user logs out of any one of theseapplications (SAML or OAuth) and wants a global logout, the user islogged out of all applications irrespective of their protocol.

In one embodiment, for SAML, there may be remote IDP authentication. TheIDP is an external party that may want to invoke its own logout. In thiscase, the embodiment implements information in the request cookie thatindicates a SAML invoked logout. Accordingly, the embodiment providesfunctionality so that remote authentication logout can be invoked.

In one embodiment, the SSO cookie is a secure host cookie intended onlyfor the IDCS hosts, and is the source of truth. No entity other thanIDCS components receives the host cookie. Instead, respective tokens aregenerated and provided to the applications that are outside of IDCS.

Login/Logout Flow

FIG. 11 is a message sequence flow 1100 of SSO functionality provided byIDCS in one embodiment. When a user uses a browser 1102 to access aclient 1106 (e.g., a browser-based application or a mobile/nativeapplication), Cloud Gate 1104 acts as an application enforcement pointand enforces a policy defined in a local policy text file. If Cloud Gate1104 detects that the user has no local application session, it requiresthe user to be authenticated. In order to do so, Cloud Gate 1104redirects browser 1102 to OAuth2 microservice 1110 to initiate OpenIDConnect login flow against the OAuth2 microservice 1110 (3-legged AZGrant flow with scopes=“openid profile”).

The request of browser 1102 traverses IDCS routing tier web service 1108and Cloud Gate 1104 and reaches OAuth2 microservice 1110. OAuth2microservice 1110 constructs the application context (i.e., metadatathat describes the application, e.g., identity of the connectingapplication, client ID, configuration, what the application can do,etc.), and redirects browser 1102 to SSO microservice 1112 to log in.

If the user has a valid SSO session, SSO microservice 1112 validates theexisting session without starting a login ceremony. If the user does nothave a valid SSO session (i.e., no session cookie exists), the SSOmicroservice 1112 initiates the user login ceremony in accordance withcustomer's login preferences (e.g., displaying a branded login page). Inorder to do so, the SSO microservice 1112 redirects browser 1102 to alogin application service 1114 implemented in JavaScript. Loginapplication service 1114 provides a login page in browser 1102. Browser1102 sends a REST POST to the SSO microservice 1112 including logincredentials. The SSO microservice 1112 generates an access token andsends it to Cloud Gate 1104 in a REST POST. Cloud Gate 1104 sends theauthentication information to Admin SCIM microservice 1116 to validatethe user's password. Admin SCIM microservice 1116 determines successfulauthentication and sends a corresponding message to SSO microservice1112.

In one embodiment, during the login ceremony, the login page does notdisplay a consent page, as “login” operation requires no furtherconsent. Instead, a privacy policy is stated on the login page,informing the user about certain profile attributes being exposed toapplications. During the login ceremony, the SSO microservice 1112respects customer's IDP preferences, and if configured, redirects to theIDP for authentication against the configured IDP.

Upon successful authentication or validation, SSO microservice 1112redirects browser 1102 back to OAuth2 microservice 1110 with the newlycreated/updated SSO host HTTP cookie (e.g., the cookie that is createdin the context of the host indicated by “HOSTURL”) containing the user'sauthentication token. OAuth2 microservice 1110 returns AZ Code (e.g., anOAuth concept) back to browser 1102 and redirects to Cloud Gate 1104.Browser 1102 sends AZ Code to Cloud Gate 1104, and Cloud Gate 1104 sendsa REST POST to OAuth2 microservice 1110 to request the access token andthe identity token. Both tokens are scoped to OAuth microservice 1110(indicated by the audience token claim). Cloud Gate 1104 receives thetokens from OAuth2 microservice 1110.

Cloud Gate 1104 uses the identity token to map the user's authenticatedidentity to its internal account representation, and it may save thismapping in its own HTTP cookie. Cloud Gate 1104 then redirects browser1102 to client 1106. Browser 1102 then reaches client 1106 and receivesa corresponding response from client 1106. From this point on, browser1102 can access the application (i.e., client 1106) seamlessly for aslong as the application's local cookie is valid. Once the local cookiebecomes invalid, the authentication process is repeated.

Cloud Gate 1104 further uses the access token received in a request toobtain “userinfo” from OAuth2 microservice 1110 or the SCIMmicroservice. The access token is sufficient to access the “userinfo”resource for the attributes allowed by the “profile” scope. It is alsosufficient to access “/me” resources via the SCIM microservice. In oneembodiment, by default, the received access token is only good for userprofile attributes that are allowed under the “profile” scope. Access toother profile attributes is authorized based on additional (optional)scopes submitted in the AZ grant login request issued by Cloud Gate1104.

When the user accesses another OAuth2 integrated connecting application,the same process repeats.

In one embodiment, the SSO integration architecture uses a similarOpenID Connect user authentication flow for browser-based user logouts.In one embodiment, a user with an existing application session accessesCloud Gate 1104 to initiate a logout. Alternatively, the user may haveinitiated the logout on the IDCS side. Cloud Gate 1104 terminates theapplication-specific user session, and initiates OAuth2 OpenID Provider(“OP”) logout request against OAuth2 microservice 1110. OAuth2microservice 1110 redirects to SSO microservice 1112 that kills theuser's host SSO cookie. SSO microservice 1112 initiates a set ofredirects (OAuth2 OP and SAML IDP) against known logout endpoints astracked in user's SSO cookie.

In one embodiment, if Cloud Gate 1104 uses SAML protocol to request userauthentication (e.g., login), a similar process starts between the SAMLmicroservice and SSO microservice 1112.

Cloud Cache

One embodiment provides a service/capability referred to as Cloud Cache.Cloud Cache is provided in IDCS to support communication withapplications that are LDAP based (e.g., email servers, calendar servers,some business applications, etc.) since IDCS does not communicateaccording to LDAP while such applications are configured to communicateonly based on LDAP. Typically, cloud directories are exposed via RESTAPIs and do not communicate according to the LDAP protocol. Generally,managing LDAP connections across corporate firewalls requires specialconfigurations that are difficult to set up and manage.

To support LDAP based applications, Cloud Cache translates LDAPcommunications to a protocol suitable for communication with a cloudsystem. Generally, an LDAP based application uses a database via LDAP.An application may be alternatively configured to use a database via adifferent protocol such as SQL. However, LDAP provides a hierarchicalrepresentation of resources in tree structures, while SQL representsdata as tables and fields. Accordingly, LDAP may be more desirable forsearching functionality, while SQL may be more desirable fortransactional functionality.

In one embodiment, services provided by IDCS may be used in an LDAPbased application to, for example, authenticate a user of theapplications (i.e., an identity service) or enforce a security policyfor the application (i.e., a security service). In one embodiment, theinterface with IDCS is through a firewall and based on HTTP (e.g.,REST). Typically, corporate firewalls do not allow access to internalLDAP communication even if the communication implements Secure SocketsLayer (“SSL”), and do not allow a TCP port to be exposed through thefirewall. However, Cloud Cache translates between LDAP and HTTP to allowLDAP based applications reach services provided by IDCS, and thefirewall will be open for HTTP.

Generally, an LDAP directory may be used in a line of business, such asmarketing and development, and defines users, groups, works, etc. In oneexample, a marketing and development business may have differenttargeted customers, and for each customer, may have their ownapplications, users, groups, works, etc. Another example of a line ofbusiness that may run an LDAP cache directory is a wireless serviceprovider. In this case, each call made by a user of the wireless serviceprovider authenticates the user's device against the LDAP directory, andsome of the corresponding information in the LDAP directory may besynchronized with a billing system. In these examples, LDAP providesfunctionality to physically segregate content that is being searched atruntime.

In one example, a wireless service provider may handle its own identitymanagement services for their core business (e.g., regular calls), whileusing services provided by IDCS in support of a short term marketingcampaign. In this case, Cloud Cache “flattens” LDAP when it has a singleset of users and a single set of groups that it runs against the cloud.In one embodiment, any number of Cloud Caches may be implemented inIDCS.

Distributed Data Grid

In one embodiment, the cache cluster in IDCS is implemented based on adistributed data grid, as disclosed, for example, in U.S. Pat. Pub. No.2016/0092540, the disclosure of which is hereby incorporated byreference. A distributed data grid is a system in which a collection ofcomputer servers work together in one or more clusters to manageinformation and related operations, such as computations, within adistributed or clustered environment. A distributed data grid can beused to manage application objects and data that are shared across theservers. A distributed data grid provides low response time, highthroughput, predictable scalability, continuous availability, andinformation reliability. In particular examples, distributed data grids,such as, e.g., the Oracle Coherence data grid from Oracle Corp., storeinformation in-memory to achieve higher performance, and employredundancy in keeping copies of that information synchronized acrossmultiple servers, thus ensuring resiliency of the system and continuedavailability of the data in the event of failure of a server.

In one embodiment, IDCS implements a distributed data grid such asCoherence so that every microservice can request access to shared cacheobjects without getting blocked. Coherence is a proprietary Java-basedin-memory data grid, designed to have better reliability, scalability,and performance than traditional relational database management systems.Coherence provides a peer to peer (i.e., with no central manager),in-memory, distributed cache.

FIG. 12 illustrates an example of a distributed data grid 1200 whichstores data and provides data access to clients 1250 and implementsembodiments of the invention. A “data grid cluster”, or “distributeddata grid”, is a system comprising a plurality of computer servers(e.g., 1220 a, 1220 b, 1220 c, and 1220 d) which work together in one ormore clusters (e.g., 1200 a, 1200 b, 1200 c) to store and manageinformation and related operations, such as computations, within adistributed or clustered environment. While distributed data grid 1200is illustrated as comprising four servers 1220 a, 1220 b, 1220 c, 1220d, with five data nodes 1230 a, 1230 b, 1230 c, 1230 d, and 1230 e in acluster 1200 a, the distributed data grid 1200 may comprise any numberof clusters and any number of servers and/or nodes in each cluster. Inan embodiment, distributed data grid 1200 implements the presentinvention.

As illustrated in FIG. 12, a distributed data grid provides data storageand management capabilities by distributing data over a number ofservers (e.g., 1220 a, 1220 b, 1220 c, and 1220 d) working together.Each server of the data grid cluster may be a conventional computersystem such as, for example, a “commodity x86” server hardware platformwith one to two processor sockets and two to four CPU cores perprocessor socket. Each server (e.g., 1220 a, 1220 b, 1220 c, and 1220 d)is configured with one or more CPUs, Network Interface Cards (“NIC”),and memory including, for example, a minimum of 4 GB of RAM up to 64 GBof RAM or more. Server 1220 a is illustrated as having CPU 1222 a,Memory 1224 a, and NIC 1226 a (these elements are also present but notshown in the other Servers 1220 b, 1220 c, 1220 d). Optionally, eachserver may also be provided with flash memory (e.g., SSD 1228 a) toprovide spillover storage capacity. When provided, the SSD capacity ispreferably ten times the size of the RAM. The servers (e.g., 1220 a,1220 b, 1220 c, 1220 d) in a data grid cluster 1200 a are connectedusing high bandwidth NICs (e.g., PCI-X or PCIe) to a high-performancenetwork switch 1220 (for example, gigabit Ethernet or better).

A cluster 1200 a preferably contains a minimum of four physical serversto avoid the possibility of data loss during a failure, but a typicalinstallation has many more servers. Failover and failback are moreefficient the more servers that are present in each cluster and theimpact of a server failure on a cluster is lessened. To minimizecommunication time between servers, each data grid cluster is ideallyconfined to a single switch 1202 which provides single hop communicationbetween servers. A cluster may thus be limited by the number of ports onthe switch 1202. A typical cluster will therefore include between 4 and96 physical servers.

In most Wide Area Network (“WAN”) configurations of a distributed datagrid 1200, each data center in the WAN has independent, butinterconnected, data grid clusters (e.g., 1200 a, 1200 b, and 1200 c). AWAN may, for example, include many more clusters than shown in FIG. 12.Additionally, by using interconnected but independent clusters (e.g.,1200 a, 1200 b, 1200 c) and/or locating interconnected, but independent,clusters in data centers that are remote from one another, thedistributed data grid can secure data and service to clients 1250against simultaneous loss of all servers in one cluster caused by anatural disaster, fire, flooding, extended power loss, and the like.

One or more nodes (e.g., 1230 a, 1230 b, 1230 c, 1230 d and 1230 e)operate on each server (e.g., 1220 a, 1220 b, 1220 c, 1220 d) of acluster 1200 a. In a distributed data grid, the nodes may be, forexample, software applications, virtual machines, or the like, and theservers may comprise an operating system, hypervisor, or the like (notshown) on which the node operates. In an Oracle Coherence data grid,each node is a Java virtual machine (“JVM”). A number of JVMs/nodes maybe provided on each server depending on the CPU processing power andmemory available on the server. JVMs/nodes may be added, started,stopped, and deleted as required by the distributed data grid. JVMs thatrun Oracle Coherence automatically join and cluster when started.JVMs/nodes that join a cluster are called cluster members or clusternodes.

Each client or server includes a bus or other communication mechanismfor communicating information, and a processor coupled to bus forprocessing information. The processor may be any type of general orspecific purpose processor. Each client or server may further include amemory for storing information and instructions to be executed byprocessor. The memory can be comprised of any combination of randomaccess memory (“RAM”), read only memory (“ROM”), static storage such asa magnetic or optical disk, or any other type of computer readablemedia. Each client or server may further include a communication device,such as a network interface card, to provide access to a network.Therefore, a user may interface with each client or server directly, orremotely through a network, or any other method.

Computer readable media may be any available media that can be accessedby processor and includes both volatile and non-volatile media,removable and non-removable media, and communication media.Communication media may include computer readable instructions, datastructures, program modules, or other data in a modulated data signalsuch as a carrier wave or other transport mechanism, and includes anyinformation delivery media.

The processor may further be coupled via bus to a display, such as aLiquid Crystal Display (“LCD”). A keyboard and a cursor control device,such as a computer mouse, may be further coupled to bus to enable a userto interface with each client or server.

In one embodiment, the memory stores software modules that providefunctionality when executed by the processor. The modules include anoperating system that provides operating system functionality eachclient or server. The modules may further include a cloud identitymanagement module for providing cloud identity management functionality,and all other functionality disclosed herein.

The clients may access a web service such as a cloud service. The webservice may be implemented on a WebLogic Server from Oracle Corp. in oneembodiment. In other embodiments, other implementations of a web servicecan be used. The web service accesses a database which stores clouddata.

As disclosed, embodiments implement a microservices based architectureto provide cloud-based multi-tenant IAM services. In one embodiment,each requested identity management service is broken into real-timetasks that are handled by a microservice in the middle tier, andnear-real-time tasks that are offloaded to a message queue. Accordingly,embodiments provide a cloud-scale IAM platform.

FIG. 13 is a flow diagram 1300 of cloud-based IAM functionality inaccordance with an embodiment. In one embodiment, the functionality ofthe flow diagram of FIG. 13 is implemented by software stored in memoryor other computer readable or tangible medium, and executed by aprocessor. In other embodiments, the functionality may be performed byhardware (e.g., through the use of an application specific integratedcircuit (“ASIC”), a programmable gate array (“PGA”), a fieldprogrammable gate array (“FPGA”), etc.), or any combination of hardwareand software.

At 1302 a first request is received for an identity management serviceconfigured to allow for accessing an application. In one embodiment, forexample, the first request is received by a security gate such as CloudGate as described herein, for example, with reference to web routingtier 610 in FIG. 6 and/or cloud gate 702 in FIG. 7. In one embodiment,the first request includes a call to an API that identifies the identitymanagement service and a microservice configured to perform the identitymanagement service. In one embodiment, the microservice is aself-contained module that can communicate with othermodules/microservices, and each microservice has an unnamed universalport that can be contacted by others. For example, in one embodiment, avariety of applications/services 602 may make HTTP calls to IDCS APIs touse IDCS microservices 614 as illustrated in FIG. 6. In one embodiment,a microservice is a runtime component/process.

At 1304 the first request is sent to a microservice, where themicroservice performs the identity management service by generating atoken, where the microservice generates the token at least in part bysending a second request to a single sign-on microservice, and where thesingle sign-on microservice is configured to provide single sign-onfunctionality across different microservices that are based on differentprotocols.

At 1306 the token is received from the microservice, and at 1308 thetoken is provided to the application, where the token allows foraccessing the application.

FIG. 14 is a logout flow illustrating various functionality ofcomponents and cookie propagation functionality in accordance with oneembodiment. Components or layers involved in FIG. 14 include the enduser client (or relying party 1 (“RP1”)) 1401, OIDC layer 1402, SSOlayer 1403 and SAML layer 1404. FIG. 14 is directed to logout and theclearing of cookies.

At 1420, client 1401 triggers a logout, typically through a logout URL.At 1421, OIDC 1402 stores a return URL for client 1401 in the cookie(e.g., IDCS_REQ cookie) that is stored on the corresponding browser ofclient 1401. The return URL could be the final successful logout landingpage of client 1401.

At 1429, the authentication context is cleared. At 1430, the SSOcomponents entry from the SSO Cookie's component data map is cleared. At1431, it is determined whether an OAuth entry is present in thecomponent data map.

If yes at 1431, an HTML 303 redirects to OIDC 1402 layer and at 1423 theOAuth entry value is read and the clientID is retrieved.

At 1424, the logout URL corresponding to the clientID is fetched. In oneembodiment, the client API is used to query the logout URL for theparticular clientID. At 1425, the OAuth components are cleared from theSSO Cookie's component data map. At 1427, an HTML response is generatedwith image tags with the src attribute set to logout URLs of the RPs.The last image tag will have src attribute set to the SSO service logoutURL. At 1428, the HTML response is rendered while executing the lastimage tag which has the src attribute to the SSO service endpoint. A newHTTP GET request will be sent to the SSO service logout endpoint. AnHTML 302 redirect moves the functionality to SSO layer 1403 wherefunctionality continues at 1429.

If no at 1431, at 1432 it is determined if an SAML entry is present inthe component data map. If yes at 1432, at 1433 it is determined if theSAML logout flag (“logoutSAMLInvoke”) is set as true in the cookie. Ifno at 1433, at 1434 the logout redirect URL value is read from thecookie. 1434 is also executed if no at 1432.

At 1435, it is determined if the logout redirect URL value is empty ornull. If yes at 1435, at 1436 the tenant's logout landing page isfetched from SSOsettings. If no at 1435, or after 1436, at 1437 it isdetermined if the SAML logout is skipped.

If yes at 1437, at 1438 an HTML 302 redirect to logout redirect URL ifpresent or redirect to the tenant logout landing page from SSOsettings.The redirect will be to the logout landing page of client 1401. Then at1426 the logout page is rendered at client 1401. If no at 1437, theun-set cookie is removed at 1439 and then functionality moves to 1438.

If yes at 1433, at 1442 an HTML 300 redirect to SAML 1404 layer performsSAML logout and triggers logout of connected SPs. At 1441, the SAMLentry is then removed from the component data map of the SSO cookie andfunctionality moves to SSO layer 1403 to 1429.

An example of the redirect URL from SAML-SP to SSO service (withsuccessful SAML assertion) with a query parameter is shown at 1442, forexample would be:http://HOST.us.oracle.com:8990/sso/v1/user/loqin?OCIS_REQ_SP=kERRx9mNY1SWxvcv5ohVeLiwL0pJAI5yLBNhZRNkK88xD. . . . The request parameter where “OCIS_REQ” is inserted is sent bySSO to protocol/channel components. From SAML to SSO, it is“OCIS_REQ_SP” as shown above. This redirect is when IDCS is configuredto authenticate the user using an on premise IdP. After the IdPsuccessfully challenged the user, the IdP redirects the user to IDCSSAML SP with SAML Assertion. IDCS SAML SP validates the SAML Assertionand maps the user to IDCS user record. IDCS SAML SP saves component Datafor SAML in the IDCS Session cookie “ORA_OCIS”. IDCS SAML SP thenredirects the user to SSO, and provides the user data in the OCIS_REQ_SPquery/post parameter as part of the 302/POSTFORM redirect from SAML toSSO. The OCIS_REQ query/form parameter is used when communicating fromSSO to SAML IdP or OAuth IdP, while the OCIS_REQ_SP query/form parameteris used when communicating from SAML SP to SSO.

The following are steps performed by the SAML SP service being used bythe SSO service to initiate an interaction with a federated SAMLIdentity Provider in accordance with one embodiment. The SSO servicewill determine how the user should be authenticated. One of thepossibilities is for Federation SSO to be used to authenticate the user:in other terms, delegating user authentication to a remote IdP, eitheron premise IdP or a Cloud service IdP used by the customer.

When the SSO service redirects the user to the Federation Service, theSSO module must be able to indicate:

-   -   Which SAML IdP should be used for Federation SSO.

When the Federation service returns the user to the SSO component, thefollowing information must be provided:

-   -   UserID;    -   Authentication Time;    -   Expiration time;    -   Federation Message attributes;    -   IdP Partner name.

At runtime during an authentication request, the SSO Service would:

-   -   Store in the Request Cookie the data requested by the SAML        Service by using the Cookie Manager        -   SSORequestFedSSOIdP: the ID of the remote IDP.    -   Redirect the user to the SAML Service authentication URL        (http://tenant-hostname/fed/v1/user/request/login).

At runtime during an authentication request, the SAML Service would:

-   -   Read the Request Cookie to extract and remove the data set by        the SSO service        -   SSORequestFedSSOIdP: the ID of the remote IDP.    -   Read the Request Cookie to extract and NOT remove the following        data        -   SSOECID: the ECID set by OAuth/SAML-IdP services. It will be            used by SAML to record events.    -   Start Federation SSO with the remote IdP;    -   Validate and map the incoming SAML Assertion to a SAML User;    -   Write in the Session Cookie to store Federation data;    -   Don't touch the existing Request cookie;    -   SAML-SP after a Federation SSO operation will create an        SSOExternalIdPResponse that would describe the result of the        Federation SSO operation:        -   ssoResponseFedSSOStatus: string indicating the status            -   SUCCESS means success;            -   Any other string is a SAML error code (e.g.:                error.samlsrv.sp.sso.bindingUnknown).        -   ssoResponseFedSSOUserID: if the operation was successful,            this field will contain the user GUID (string).        -   ssoResponseFedSSOldP: if the operation was successful, this            field will contain the IdP partner name (string).        -   ssoResponseFedSSONameID: if the operation was successful,            this field will contain the SAML Assertion NameID (string).        -   ssoResponseFedSSOReturnURL: if the operation was successful,            and if the flow was not initiated by the SSO service, this            field will contain the URL where the user needs to be            redirected (string).        -   ssoResponseFedSSOAssertionAttributes: if the operation was            successful, this field will contain the SAML Assertion            Attributes (Map).        -   ssoResponseFedSSOTimeout: if the operation was successful,            this field will contain IdP session timeout (long).        -   ssoECID: contains the ECID.        -   idcsSSOInitiated: contains whether or not the flow was            started by the SSO service (boolean)            -   If false, then the SSO service will need to check                ssoResponseFedSSOReturnURL                -   If ssoResponseFedSSOReturnURL is null, then SSO                    service will remove the IDCS Request Cookie and                    redirect to MyConsole;                -   Otherwise, SSO service will remove the IDCS Request                    Cookie and redirect to ssoResponseFedSSOReturnURL;            -   If true, the SSO service will redirect to the                callbackURL, since the Federation SSO flow was started                by IDCS SSO service.    -   The redirect URL from SAML-SP to SSO service for example would        be:        “http://HOST.us.oracle.com:8990/sso/v1/user/loqin?OCIS_REQ_SP=kERRx9mNY1SWxvcv5ohVeLjwL0pJAI5yLBNhZRNkK88xD        . . . ”

At runtime during an authentication response, the SSO Service would:

-   -   SSO service will retrieve the value for the query parameter        OCIS_REQ_SP and decode it and reads the data set by the SAML        service        -   SSOResponseFedSSOStatus: SUCCESS indicates a success,            FAILURE will come with an error code (e.g.            error.samlsrv.sp.sso.assertion.noUserReturnedViaNameID)SSOResponseFedSSOUserID:            the IDCS UserID in case of a success;        -   SSOResponseFedSSOIdP: the ID of the remote IdP;        -   SSOResponseFedSSOTimeout: the time at which the IdP session            will timeout in seconds (set to −1);        -   SSOResponseFedSSONameID: the identifier used in the SAML            Assertion NameID field;        -   SSOResponseFedSSOReturnURL: the URL where the user should be            redirected after the SSO service creates an IDCS session.            This parameter will only be set during an IdP initiated SSO            flow;        -   SSOResponseFedSSOAssertionAttributes: the list of attributes            contained in the SAML SSO Assertion.    -   Read the Request Cookie to extract and remove it:        -   SSOECID: the ECID set by OAuth/SAML-IdP services. It will be            used by SSO to record event;        -   rpId, rpName.    -   Create an IDCS session for the user and store the data in the        Session Cookie    -   Redirect the user to:    -   idcsSSOInitiated: contains whether or not the flow was started        by the SSO service (boolean);        -   If false, then the SSO service will need to check            ssoResponseFedSSOReturnURL;            -   If ssoResponseFedSSOReturnURL is null, then SSO service                will remove the IDCS Request Cookie and redirect to                MyConsole;            -   Otherwise, SSO service will remove the IDCS Request                Cookie and redirect to ssoResponseFedSSOReturnURL.        -   If true, the SSO service will redirect to the callbackURL,            since the Federation SSO flow was started by IDCS SSO            service.

In one embodiment, the SSO functions/steps for performing SLO are asfollows:

1. Remove user's session from the session cookie, i.e. AuthNContext.

2. For OAuth entry in component data, if present, redirect to OAuthlogout endpoint.

3. OAuth/OIDC fetches RP's logout URLs from client ids, clears OAuthentry from component Data, produces HTML source with different RP LogoutURLs (async process), finally coming back to SSO Logout (last img src isSSO Logout).

4. SSO checks for SAML entry in component data, if exits, check for the“do not invoke SAML flag” in IDCS_REQ cookie, if set to true or does notexist, delegate to SAML/logout by redirect, SAML completes its SP logoutflow, clear SAML entry from component Data and come back to SSO/logout.

5. The SAML service starts the SAML 2.0 Logout protocol operation andredirects the user to the various remote Federation partners for logout.

6. Once done, the SAML service deletes the SAML data from the IDCSSession Cookie.

7. The SAML service redirects the user to the SSO service (URL TBD fromSSO Service).

8. SSO logout gets “return URL”, clear session cookie (SAML componentdata must not be removed if present) and finally redirect to “returnURL”. If “return URL” does not exist, then redirect to Tenant specificlogout landing page.

In one embodiment, the microservice is configured to provide anauthentication functionality based on a protocol. In one embodiment, theprotocol is OAuth or SAML, and the single sign-on microservice isconfigured to provide single sign-on functionality across both OAuth andSAML. In one embodiment, the single sign-on microservice generates aglobal session configured as a session cookie and provides the globalsession to the microservice. In one embodiment, the microserviceconverts the global session into the token. In one embodiment, thesingle sign-on microservice normalizes request parameters of the secondrequest.

In one embodiment, the application is configured to be used by multipletenancies including the tenancy. In one embodiment, the microservice isstateless and retrieves data from a database to perform the identitymanagement service. In one embodiment, the database and the microserviceare configured to scale independently of one another. In one embodiment,the database includes a distributed data grid.

As disclosed, embodiments provide a multi-tenant, cloud-scale, IAM thatprovides SSO functionality across various protocols by implementing aglobal session and converting the global session to appropriate protocoltokens. Further, embodiments use a cookie and redirects to perform SLOfunctionality for all applications.

Several embodiments are specifically illustrated and/or describedherein. However, it will be appreciated that modifications andvariations of the disclosed embodiments are covered by the aboveteachings and within the purview of the appended claims withoutdeparting from the spirit and intended scope of the invention.

What is claimed is:
 1. A non-transitory computer readable medium havinginstructions stored thereon that, when executed by a processor, causethe processor to provide cloud-based identity and access management, theproviding comprising: receiving a first request for an identitymanagement service configured to allow for accessing applications;sending the first request to a first microservice, wherein the firstmicroservice performs the identity management service by generating atoken, wherein the first microservice generates the token at least inpart by sending a second request to a single sign-on (SSO) microservice,wherein the SSO microservice is configured to provide SSO functionalityacross different microservices that are based on different protocols;wherein the SSO microservice implements an SSO and generates a cookiethat includes a global state and is used for communicating withdifferent microservices; receiving a single log-out (SLO) of the SSO;and using the cookie to iteratively log-out of the applications,wherein, after each log-out of an application of a first protocol, aredirect is performed to the SSO microservice to trigger log-out ofapplications of a different protocol.
 2. The computer readable medium ofclaim 1, wherein the cookie indicates applications that are signed intothe SSO.
 3. The computer readable medium of claim 1, further comprising:receiving the token from the first microservice; and providing the tokento an application, wherein the token allows for accessing theapplication.
 4. The computer readable medium of claim 1, wherein thefirst microservice is configured to provide an authenticationfunctionality based on the protocol.
 5. The computer readable medium ofclaim 4, wherein the protocol is OAuth or Security Assertion MarkupLanguage (SAML), wherein the SSO microservice is configured to provideSSO functionality across both OAuth and SAML.
 6. The computer readablemedium of claim 5, wherein the SSO microservice generates a globalsession configured as a session cookie and provides the global sessionto the first microservice.
 7. The computer readable medium of claim 6,wherein the first microservice converts the global session into thetoken.
 8. A method of providing cloud-based identity and accessmanagement comprising: receiving a first request for an identitymanagement service configured to allow for accessing applications;sending the first request to a first microservice, wherein the firstmicroservice performs the identity management service by generating atoken, wherein the first microservice generates the token at least inpart by sending a second request to a single sign-on (SSO) microservice,wherein the SSO microservice is configured to provide SSO functionalityacross different microservices that are based on different protocols;wherein the SSO microservice implements an SSO and generates a cookiethat includes a global state and is used for communicating withdifferent microservices; receiving a single log-out (SLO) of the SSO;and using the cookie to iteratively log-out of the applications,wherein, after each log-out of an application of a first protocol, aredirect is performed to the SSO microservice to trigger log-out ofapplications of a different protocol.
 9. The method of claim 8, whereinthe cookie indicates applications that are signed into the SSO.
 10. Themethod of claim 8, further comprising: receiving the token from thefirst microservice; and providing the token to an application, whereinthe token allows for accessing the application.
 11. The method of claim8, wherein the first microservice is configured to provide anauthentication functionality based on the protocol.
 12. The method ofclaim 11, wherein the protocol is OAuth or Security Assertion MarkupLanguage (SAML), wherein the SSO microservice is configured to provideSSO functionality across both OAuth and SAML.
 13. The method of claim12, wherein the SSO microservice generates a global session configuredas a session cookie and provides the global session to the firstmicroservice.
 14. The method of claim 13, wherein the first microserviceconverts the global session into the token.
 15. A system for providingcloud based identity and access management, comprising: a plurality oftenants; a plurality of microservices; and one or more processors that:receive a first request for an identity management service configured toallow for accessing applications; send the first request to a firstmicroservice, wherein the first microservice performs the identitymanagement service by generating a token, wherein the first microservicegenerates the token at least in part by sending a second request to asingle sign-on (SSO) microservice, wherein the SSO microservice isconfigured to provide SSO functionality across different microservicesthat are based on different protocols; wherein the SSO microserviceimplements an SSO and generates a cookie that includes a global stateand is used for communicating with different microservices; receive asingle log-out (SLO) of the SSO; and use the cookie to iterativelylog-out of the applications, wherein, after each log-out of anapplication of a first protocol, a redirect is performed to the SSOmicroservice to trigger log-out of applications of a different protocol.16. The system of claim 15, wherein the cookie indicates applicationsthat are signed into the SSO.
 17. The system of claim 15, furthercomprising: receiving the token from the first microservice; andproviding the token to an application, wherein the token allows foraccessing the application.
 18. The system of claim 15, wherein the firstmicroservice is configured to provide an authentication functionalitybased on the protocol.
 19. The system of claim 18, wherein the protocolis OAuth or Security Assertion Markup Language (SAML), wherein the SSOmicroservice is configured to provide SSO functionality across bothOAuth and SAML.
 20. The system of claim 19, wherein the SSO microservicegenerates a global session configured as a session cookie and providesthe global session to the first microservice.